即刻App年轻人的同好社区
下载
如何把达人投放从临时救火变成 Agentic Workflow，在Twitter做campaign？（可复用SOP复盘）
结论先行
达人 quote amplification 不能只靠“找一批看起来不错的人发帖”。真正需要管理的是一整套动态系统：候选池、近期数据、历史表现、触达路径、预算、回复速度、发布窗口、稿件质量、付款和复盘。AI agent 最适合承担信息收拢和状态追踪，人负责关键判断和外部承诺。
过去发生了什么
近期产品 Launch 前，我们需要在固定时间窗口内组织 20-30 个 Twitter/X 达人 quote 官方发布帖，希望放大官方帖的早期声量。
表面上看，这是一个找达人合作的问题。实际推进时，它变成了一个多变量协调问题：历史合作记录分散在不同表格和文件里；部分达人是自己 DM，部分需要 agency 协助；有些达人历史表现好但近期 views 低；有些账号粉丝数高但实际帖子只有几百 views；还有人提供矩阵号、bundle、补充账号，容易造成重复建联和预算膨胀。
同时，Launch 时间固定，达人回复不可控，内部 brief 和官方帖内容也不是一开始就完全 ready。
导致了什么问题
第一，筛选标准会在压力下漂移。
一开始容易纠结“是否足够 to dev”“是否营销味太重”。但对于 quote amplification，核心目标其实是 reach。过度追求垂直，会错过真正能带 views 的账号；只追求 views，又可能选到错圈层账号。
第二，历史数据会误导。
一个达人以前表现好，不代表这次表现一定好。账号近期状态、内容方向、发布时间、平台分发都会变化。历史表现只能作为 trust signal，不能替代近期数据。
第三，agency 能联系到，不等于最值得联系。
Agency 的价值是紧急补量和关系触达，但它能快速确认的人，往往是“可达的人”，不一定是“最强的人”。如果不区分，容易把 volume insurance 当成 reach engine。
第四，预算风险会积累。
达人一个个回复报价时，如果没有实时总价表，很容易从一个看起来合理的小预算，滚到更高金额。尤其当你已经向达人确认合作后，再因为内部预算不确定反悔，会损害外部信誉。
第五，发布节奏会失控。
原计划可能是 0h / 1h / 2h / 4h 分波发布，但如果通知里用 around 这类模糊表达，达人可能集中在第一小时发完，后续推力变弱。
用过什么方法解决
我在过程中尝试了这些 agentic workflow。
第一步，让 agent 收拢所有候选来源：历史合作表、agency 名单、Notion、Slack 信息、本地文件、DM 记录、公开主页表现。先建立 master list，而不是边看边判断。
第二步，用近期真实 views 作为主排序。只看本人主帖或高质量 quote，不把 retweet 继承 views、reply 活跃度、粉丝数当成核心指标。
第三步，做内容硬过滤。AI、developer、tools、startup、builder、productivity 相关可以保留；体育、meme、纯娱乐、airdrop、低质赚钱内容，即使 views 高也降级或剔除。
第四步，把达人分成三类：
Reach Engine：近期真实 views 强，负责主要扩散。
History-Trusted：历史合作好，可信度高。
Volume Insurance：用于保证数量和发布窗口覆盖。
第五步，Direct 和 agency 分开管理。Direct 适合高价值目标，成本效率更好；agency 用于补量和兜底，但需要单独计算 CPM 和预期。
第六步，所有状态进入 tracker：是否已 DM、是否回复、报价、是否确认、draft 是否通过、发布时间、payment method、publish link、views。
结果如何
最终，表现最好的部分达人确实来自这套 reach-first 筛选逻辑：近期 views 强、历史合作可信、且 direct 沟通效率高的人，整体成本效率更好。
但也出现了现实偏差：有些按标准筛出来的人表现不佳，尤其是通过 agency 紧急建联的一部分。原因不是单一的“选错”，而是：
近期高 views 是概率信号，不是承诺。
历史爆款可能依赖特定内容类型，不能完全迁移。
Agency route 受可达性限制，不是纯按最优名单执行。
部分人本来就是补量位，不应按主力位预期。
发布节奏集中，削弱了持续扩散。
部分公开数据本身是近似值，不是实时精确 API。
我的方案是什么
结束后，我尝试把这件事沉淀成一个 Launch Influencer Operating System，而不是临时投放流程。
它包括八个 agentic 模块：
Source：收拢所有候选来源并去重。
Scoring：按近期真实 views、内容 fit、历史表现、价格、风险打标签。
Risk：识别错圈层、reply-heavy、retweet 继承、低质营销号。
Routing：决定 Direct / Agency / Bundle，并做重复触达检查。
Outreach：根据是否合作过生成 DM。
Brief：生成统一 launch brief 和达人可用角度。
Draft Review：检查 quote 文案是否自然、准确、无 unsupported claim。
Tracking：追踪报价、发布、付款、表现和复盘。
优势是什么
第一，减少人工过度摄入。
人不用反复刷主页和翻聊天记录，而是只看 agent 标出来的异常、排序和决策点。
第二，保留现实约束。
不是只做理想排序，而是把回复速度、agency 可达性、预算上限、发布时间、外部信誉风险都纳入系统。
第三，减少承诺风险。
在确认达人前，系统可以实时显示已确认人数、预计总价、Direct / Agency 占比、预算变化。
第四，形成复利。
每次 campaign 的最终表现都会回填，下一次不再从零开始选人。
具体推进的timeline优化
T-7：确定目标、预算上限、发布时间、需要 quote 数量。
T-5：agent 收拢全量候选池，生成 P0 / P1 / Reserve。
T-3：完成人工复核，锁定 Direct P0，agency 只作为补量路线。
T-2：发出 DM，记录回复速度和报价。
T-1：确认 brief、draft、payment method、发布窗口。
Launch Day：按精确 PT 时间窗口分波通知。
T+1：回收 publish links、views、互动、CPM。
T+3：复盘哪些人进入长期 Reach Engine，哪些只保留为补量。
成本如何
成本应该分层计算，而不是只看总价。
Direct Reach Engine：通常 CPM 更好，但需要提前建联。
History-Trusted：适合复用，但要重新检查近期状态。
Agency Volume Insurance：适合紧急保量，但平均 CPM 可能更高。
Bundle：只有在去重后确认增量账号质量时才值得买。
下次最理想的状态是：
提前维护一个动态 creator table，AI agent 每周刷新近期数据和状态；Launch 来临时，只需要更新目标和预算，就能快速生成名单、触达策略、brief、tracker 和复盘框架。
这类工作最后不是“达人投放”，而是一个小型的 agentic operations system：
把混乱的外部现实拆成可追踪的状态、可复用的判断和可迭代的数据资产。
结论先行
达人 quote amplification 不能只靠“找一批看起来不错的人发帖”。真正需要管理的是一整套动态系统：候选池、近期数据、历史表现、触达路径、预算、回复速度、发布窗口、稿件质量、付款和复盘。AI agent 最适合承担信息收拢和状态追踪，人负责关键判断和外部承诺。
过去发生了什么
近期产品 Launch 前，我们需要在固定时间窗口内组织 20-30 个 Twitter/X 达人 quote 官方发布帖，希望放大官方帖的早期声量。
表面上看，这是一个找达人合作的问题。实际推进时，它变成了一个多变量协调问题：历史合作记录分散在不同表格和文件里；部分达人是自己 DM，部分需要 agency 协助；有些达人历史表现好但近期 views 低；有些账号粉丝数高但实际帖子只有几百 views；还有人提供矩阵号、bundle、补充账号，容易造成重复建联和预算膨胀。
同时，Launch 时间固定，达人回复不可控，内部 brief 和官方帖内容也不是一开始就完全 ready。
导致了什么问题
第一，筛选标准会在压力下漂移。
一开始容易纠结“是否足够 to dev”“是否营销味太重”。但对于 quote amplification，核心目标其实是 reach。过度追求垂直，会错过真正能带 views 的账号；只追求 views，又可能选到错圈层账号。
第二，历史数据会误导。
一个达人以前表现好，不代表这次表现一定好。账号近期状态、内容方向、发布时间、平台分发都会变化。历史表现只能作为 trust signal，不能替代近期数据。
第三，agency 能联系到，不等于最值得联系。
Agency 的价值是紧急补量和关系触达，但它能快速确认的人，往往是“可达的人”，不一定是“最强的人”。如果不区分，容易把 volume insurance 当成 reach engine。
第四，预算风险会积累。
达人一个个回复报价时，如果没有实时总价表，很容易从一个看起来合理的小预算，滚到更高金额。尤其当你已经向达人确认合作后，再因为内部预算不确定反悔，会损害外部信誉。
第五，发布节奏会失控。
原计划可能是 0h / 1h / 2h / 4h 分波发布，但如果通知里用 around 这类模糊表达，达人可能集中在第一小时发完，后续推力变弱。
用过什么方法解决
我在过程中尝试了这些 agentic workflow。
第一步，让 agent 收拢所有候选来源：历史合作表、agency 名单、Notion、Slack 信息、本地文件、DM 记录、公开主页表现。先建立 master list，而不是边看边判断。
第二步，用近期真实 views 作为主排序。只看本人主帖或高质量 quote，不把 retweet 继承 views、reply 活跃度、粉丝数当成核心指标。
第三步，做内容硬过滤。AI、developer、tools、startup、builder、productivity 相关可以保留；体育、meme、纯娱乐、airdrop、低质赚钱内容，即使 views 高也降级或剔除。
第四步，把达人分成三类：
Reach Engine：近期真实 views 强，负责主要扩散。
History-Trusted：历史合作好，可信度高。
Volume Insurance：用于保证数量和发布窗口覆盖。
第五步，Direct 和 agency 分开管理。Direct 适合高价值目标，成本效率更好；agency 用于补量和兜底，但需要单独计算 CPM 和预期。
第六步，所有状态进入 tracker：是否已 DM、是否回复、报价、是否确认、draft 是否通过、发布时间、payment method、publish link、views。
结果如何
最终，表现最好的部分达人确实来自这套 reach-first 筛选逻辑：近期 views 强、历史合作可信、且 direct 沟通效率高的人，整体成本效率更好。
但也出现了现实偏差：有些按标准筛出来的人表现不佳，尤其是通过 agency 紧急建联的一部分。原因不是单一的“选错”，而是：
近期高 views 是概率信号，不是承诺。
历史爆款可能依赖特定内容类型，不能完全迁移。
Agency route 受可达性限制，不是纯按最优名单执行。
部分人本来就是补量位，不应按主力位预期。
发布节奏集中，削弱了持续扩散。
部分公开数据本身是近似值，不是实时精确 API。
我的方案是什么
结束后，我尝试把这件事沉淀成一个 Launch Influencer Operating System，而不是临时投放流程。
它包括八个 agentic 模块：
Source：收拢所有候选来源并去重。
Scoring：按近期真实 views、内容 fit、历史表现、价格、风险打标签。
Risk：识别错圈层、reply-heavy、retweet 继承、低质营销号。
Routing：决定 Direct / Agency / Bundle，并做重复触达检查。
Outreach：根据是否合作过生成 DM。
Brief：生成统一 launch brief 和达人可用角度。
Draft Review：检查 quote 文案是否自然、准确、无 unsupported claim。
Tracking：追踪报价、发布、付款、表现和复盘。
优势是什么
第一，减少人工过度摄入。
人不用反复刷主页和翻聊天记录，而是只看 agent 标出来的异常、排序和决策点。
第二，保留现实约束。
不是只做理想排序，而是把回复速度、agency 可达性、预算上限、发布时间、外部信誉风险都纳入系统。
第三，减少承诺风险。
在确认达人前，系统可以实时显示已确认人数、预计总价、Direct / Agency 占比、预算变化。
第四，形成复利。
每次 campaign 的最终表现都会回填，下一次不再从零开始选人。
具体推进的timeline优化
T-7：确定目标、预算上限、发布时间、需要 quote 数量。
T-5：agent 收拢全量候选池，生成 P0 / P1 / Reserve。
T-3：完成人工复核，锁定 Direct P0，agency 只作为补量路线。
T-2：发出 DM，记录回复速度和报价。
T-1：确认 brief、draft、payment method、发布窗口。
Launch Day：按精确 PT 时间窗口分波通知。
T+1：回收 publish links、views、互动、CPM。
T+3：复盘哪些人进入长期 Reach Engine，哪些只保留为补量。
成本如何
成本应该分层计算，而不是只看总价。
Direct Reach Engine：通常 CPM 更好，但需要提前建联。
History-Trusted：适合复用，但要重新检查近期状态。
Agency Volume Insurance：适合紧急保量，但平均 CPM 可能更高。
Bundle：只有在去重后确认增量账号质量时才值得买。
下次最理想的状态是：
提前维护一个动态 creator table，AI agent 每周刷新近期数据和状态；Launch 来临时，只需要更新目标和预算，就能快速生成名单、触达策略、brief、tracker 和复盘框架。
这类工作最后不是“达人投放”，而是一个小型的 agentic operations system：
把混乱的外部现实拆成可追踪的状态、可复用的判断和可迭代的数据资产。
6 43
我用AI读完了盖洛普报告，最后还是被真人咨询 @自由的大鱼 改变了。
我原来以为，AI 已经足够懂我的盖洛普报告了。毕竟我已经用这种方式读了星盘、八字、荣格八维...
它能读官方报告，能把 34 项才干展开成一套很漂亮的分析，也能顺着我的自我材料，帮我整理出很多“原来我是这样”的解释。信息量很大，结构也很完整。按理说，对一个长期用 AI 做自我分析的人来说，这应该已经够了。
直到 4 月 30 日，我做了一次真人优势咨询，然后给自己留了两周观察期。我后来才发现，这件事最重要的变化不在“真人比 AI 多说了什么”，而在于：真人把我从自己的解释系统里拽出来了一下。
AI 的解读有一个很微妙的特点。它不一定是在夸我，但它经常是“正向”的。这里的正向不是情绪上的正面，而是它会顺着我已经提供的语言、框架和关注点继续往下推。它很擅长把我已经说得出来的东西说得更完整、更好看、更系统。
这也让我想到芒格说的逆向思维。AI 可以在我的框架里给出正向结论、负向结论，甚至反向结论，但它仍然很可能是在同一套思维结构里打转。真人的作用不是“给一个相反答案”，而是用另一个人的经验和现场感受，帮我看见我原来的框架本身。
但真人咨询不是这样。
真人更像一面不完全受我控制的镜子。它不只接收我整理好的文本，也接收我在互动现场的停顿、急着解释、想补充背景、想把每个概念讲完整、想证明自己已经理解了的冲动。这些东西我不会主动交给 AI，甚至我自己也未必意识到它正在发生。
这也是我这次对“才干”理解被改写的地方。
咨询前，我会很自然地把才干理解成优势、天赋、优点，或者某种更好听的人格标签。AI 也很容易这样解释，因为这种解释更顺滑，更容易给人即时正反馈。
但真人咨询让我真正听懂的一句话是：才干不是固定的优点，而是事件发生时，一个人最容易自动启动的默认反应链。
这个定义一下子把很多东西接上了。它让我想到《清晰思考》里说的默认值，也让我想到 CBT 里的 ABC 理论，还让我重新理解“命运”这件事：如果一个人永远只是顺着自己的默认反应走，他看起来在选择，其实是在被惯性推着走；但如果他能看见自己的默认链条，命运才第一次出现了可以被调方向的空间。
所以盖洛普最有价值的地方，可能根本不是告诉我“你有什么优势”，而是帮我看见：我在什么场景下，会不由自主地成为一个什么样的人。
这里也让我更理解专业术语的意义。术语不是装饰，它是进入一个领域的入场券。如果一开始就把“才干”误读成“优点”，后面所有自我归因都会沿着这个偏差继续展开。就像练武如果基本功一开始就歪了，前期也可能因为新鲜感和正反馈觉得自己进步很快，但越往后越难纠偏。
AI 很适合帮我扩大和加速这个系统，但它很难替我完成一开始的校准。因为它看到的，首先是我愿意输入给它的材料。
而人和人的互动，会暴露更多我无法完全控制的信号。
我以前更喜欢线上交流，这件事现在回头看，不只是因为线上高效，也不只是因为文字可以沉淀。更深一层是：线上让我更安全。文字里，我可以控制节奏、修饰表达、删掉停顿、隐藏那些还没想清楚但已经开始反应的部分。
从信息复杂度上看，AI 文本交流、线上文字、语音、视频、线下面对面，几乎是一层一层往下加信息量。越往线下走，越会出现那些非主观控制的微反应：语气、眼神、身体姿态、停顿、急促、回避、想解释、想防御。
过去我更像一个防卫者，倾向于减少别人能读到我的信号。现在我开始更愿意成为一个观察者。前提是对方值得信任。因为线下并不只是“暴露自己”，它也是更真实地观察他人、理解他人、接住他人的场域。
这也是真人反馈为什么会比 AI 更留在我脑子里。
AI 可以给我一整屏很完整的结论，但它通常停留在“当下觉得有道理”。真人的一些话，信息密度未必更高，却会在两周后的具体场景里突然闪回。
比如，大鱼提醒我，我很容易给别人太多 content 作为前置信息。
这句话后来反复出现。无论是工作里解释一个问题，还是关系里试图让对方理解我的感受，我都会本能地想把背景、逻辑、证据、上下文一次性交给对方。我以为这是帮助对方理解，但它也可能是在把我的处理负荷转移给对方。
我过去很容易默认：只要我给得足够完整，对方就会更理解我。现在我开始多问一层：对方此刻真的需要这么多信息吗？他现在接得住吗？他需要的是材料，还是感受先被确认？
另一个反复闪回的是“标准外溢”。
我的完美、成就、行动、沟通、搜集、战略这些高位才干，在很多时候确实帮我把事情做快、做深、做完整。但它们也会在不知不觉中形成一种气场：即使我没有开口要求别人达到我的标准，别人也可能感受到压力。
这对我很重要。因为我过去会觉得，只要我没有明确要求别人，我就没有把标准强加给别人。但现在我开始意识到，人的影响不只发生在语言里，也发生在节奏里、边界里、默认期待里。
工作里的验证非常直接。
有一次对方其实只需要几个关键点和简单案例，我本能地顺着自己的标准做成了一套更完整的分析。事情没有坏，但它让我很清楚地看见：我习惯用 80 分的方式交付，而有些场景只需要 50 分。
“50 和 80 对最终结果可能没有本质差异”这句话，对我这两周的工作状态影响很大。它没有让我变敷衍，反而让我开始区分：什么是结果真正需要的质量，什么只是我为了安抚自己的完美主义而加上去的额外重量。
这背后还有一个更底层的责任边界。过去我会很容易把“我能控制的部分”扩张成“我应该负责的全部”。但很多工作场景里，真正有效的是把任务推进到当前系统需要的位置，而不是把它打磨到我自己心里的理想状态。
我也更能解释自己为什么有些任务启动很快，有些任务迟迟不开始。
当一件事有信息、有结构、有边界、有明确反馈，或者可以被拆成流程和 SOP，我的行动、搜集、战略、成就、完美会很快被点燃。我会进入一种近乎自动化的高效状态。
但这也提醒我，行动不等于稳定地长期推进。它更像一种很快进入现场、很快启动反应的能力。真正要练的不是一味更快，而是大鱼说的那种“慢快”：该快的时候快，该停下来等反馈、看边界、让事情自然发酵的时候，能慢得下来。
但当一件事反馈很慢、边界模糊、控制感低、很难判断做多少算够，我就会明显卡住。以前我可能只会责备自己拖延。现在我会先问：这件事没有满足我哪一种才干的启动条件？我是不是需要先补一个结构、补一个反馈点、补一个最低可交付边界？
这也是 AI 在咨询后的新位置。
它不再只是“帮我解释我是谁”，而是可以根据我的才干模式，帮我设计更适合自己的行动链条。比如先帮我把任务拆成可启动的步骤，设定 50 分交付线，标出哪些地方不值得过度完美，哪些地方需要用外部反馈补足低控制感。
某种意义上，盖洛普进入我的工作系统后，不是变成一堆需要背诵的标签，而是变成一个外置架构。它不一定每天占据我的主观记忆，但它会影响我怎么设计流程、怎么判断卡点、怎么处理 Plan-Fact Gap。
这件事也进入了我的 Life OS。
Daily 不再只是记录我有没有完成计划，而是帮我看见：计划和事实之间的差距，到底来自判断错误、睡眠和出行导致的身体容量变化、关系事件打断，还是默认反应链失控。关系维护也不再只是记录事件，而是更关注容量、节奏、隐私边界和对方能不能接住。甚至我对公开输出的理解，也从“把体验立刻资产化”，变成先确认它是否真的被现实调用过、是否有足够有效的反馈回路。
盖洛普给我的不是一个新的自我标签，而是一套更精细的自我观测仪表盘。
它让我看见，高位才干并不会自动等于优势。
行动让我能快速启动，也可能让我太急着进入执行。
搜集让我能建立丰富上下文，也可能让我给别人过量信息。
完美让我追求高标准，也可能让我不分场景地过度交付。
战略让我总想找到更优路径，也可能让我难以接受慢变量和低控制。
沟通让我擅长表达，也可能让我在关系里过度解释。
成就让我持续推进，也可能让我把休息和生活也变成待完成事项。
这些东西本身都不是问题。真正的问题是：我有没有看见它们正在启动？我有没有给它们合适的容器？我有没有在不适合的场景里，还继续让它们全功率运行？
这两周还有一个很大的变化，是我不再那么纠结“我和别人到底一样还是不一样”。
盖洛普让我看到，即使两个人达成了相似结果，背后的才干组合和反应路径也可能完全不同。有人靠稳定积累，有人靠战略判断，有人靠关系连接，有人靠高强度行动。结果相似，不代表路径相同。
这让我对“独特性”的理解变得松弛了一点。独特性不是一定要做出一个别人没见过的结果，而是我能不能看见自己如何自然地抵达那里，以及我是否愿意尊重这条路径。
所以如果要总结这次咨询对我的影响，我觉得不是“我更了解自己的优势了”这么简单。
更准确地说，是我开始学会在行为发生之前，看见那个准备自动反应的自己。
我开始能更早地识别：此刻我是不是又想把信息给全？是不是又想把 50 分任务做成 80 分？是不是又把自己的标准外溢给别人？是不是又把低反馈、低控制的任务解释成自己不够努力？是不是身体已经不在状态，但大脑还在要求系统继续运转？
接下来真正要练的，大概就是这些很朴素的事：
先判断场景需要 50 还是 80。
先确认对方需要感受、方向，还是材料。
先给高位才干一个边界，而不是让它们自动接管全场。
在低控制、低反馈的任务里，允许一个不完美但可推进的版本先出现。
在关系里，少一点“我把全部上下文都给你”，多一点“你现在能接住多少”。
在身体状态变化时，把执行力波动当作系统信号，而不是道德问题。
我现在也更能理解真人咨询的不可替代性了。
它不是因为 AI 不够聪明。恰恰相反，AI 已经很聪明，聪明到可以帮我搭建大量结构。但人的价值在于，他会出现在一个真实互动现场里，成为那个不完全按照我输入材料运转的他者。
AI 帮我把系统搭得更快，真人咨询让我开始看见，系统之外那个正在反应的人。
我原来以为，AI 已经足够懂我的盖洛普报告了。毕竟我已经用这种方式读了星盘、八字、荣格八维...
它能读官方报告，能把 34 项才干展开成一套很漂亮的分析，也能顺着我的自我材料，帮我整理出很多“原来我是这样”的解释。信息量很大，结构也很完整。按理说，对一个长期用 AI 做自我分析的人来说，这应该已经够了。
直到 4 月 30 日，我做了一次真人优势咨询，然后给自己留了两周观察期。我后来才发现，这件事最重要的变化不在“真人比 AI 多说了什么”，而在于：真人把我从自己的解释系统里拽出来了一下。
AI 的解读有一个很微妙的特点。它不一定是在夸我，但它经常是“正向”的。这里的正向不是情绪上的正面，而是它会顺着我已经提供的语言、框架和关注点继续往下推。它很擅长把我已经说得出来的东西说得更完整、更好看、更系统。
这也让我想到芒格说的逆向思维。AI 可以在我的框架里给出正向结论、负向结论，甚至反向结论，但它仍然很可能是在同一套思维结构里打转。真人的作用不是“给一个相反答案”，而是用另一个人的经验和现场感受，帮我看见我原来的框架本身。
但真人咨询不是这样。
真人更像一面不完全受我控制的镜子。它不只接收我整理好的文本，也接收我在互动现场的停顿、急着解释、想补充背景、想把每个概念讲完整、想证明自己已经理解了的冲动。这些东西我不会主动交给 AI，甚至我自己也未必意识到它正在发生。
这也是我这次对“才干”理解被改写的地方。
咨询前，我会很自然地把才干理解成优势、天赋、优点，或者某种更好听的人格标签。AI 也很容易这样解释，因为这种解释更顺滑，更容易给人即时正反馈。
但真人咨询让我真正听懂的一句话是：才干不是固定的优点，而是事件发生时，一个人最容易自动启动的默认反应链。
这个定义一下子把很多东西接上了。它让我想到《清晰思考》里说的默认值，也让我想到 CBT 里的 ABC 理论，还让我重新理解“命运”这件事：如果一个人永远只是顺着自己的默认反应走，他看起来在选择，其实是在被惯性推着走；但如果他能看见自己的默认链条，命运才第一次出现了可以被调方向的空间。
所以盖洛普最有价值的地方，可能根本不是告诉我“你有什么优势”，而是帮我看见：我在什么场景下，会不由自主地成为一个什么样的人。
这里也让我更理解专业术语的意义。术语不是装饰，它是进入一个领域的入场券。如果一开始就把“才干”误读成“优点”，后面所有自我归因都会沿着这个偏差继续展开。就像练武如果基本功一开始就歪了，前期也可能因为新鲜感和正反馈觉得自己进步很快，但越往后越难纠偏。
AI 很适合帮我扩大和加速这个系统，但它很难替我完成一开始的校准。因为它看到的，首先是我愿意输入给它的材料。
而人和人的互动，会暴露更多我无法完全控制的信号。
我以前更喜欢线上交流，这件事现在回头看，不只是因为线上高效，也不只是因为文字可以沉淀。更深一层是：线上让我更安全。文字里，我可以控制节奏、修饰表达、删掉停顿、隐藏那些还没想清楚但已经开始反应的部分。
从信息复杂度上看，AI 文本交流、线上文字、语音、视频、线下面对面，几乎是一层一层往下加信息量。越往线下走，越会出现那些非主观控制的微反应：语气、眼神、身体姿态、停顿、急促、回避、想解释、想防御。
过去我更像一个防卫者，倾向于减少别人能读到我的信号。现在我开始更愿意成为一个观察者。前提是对方值得信任。因为线下并不只是“暴露自己”，它也是更真实地观察他人、理解他人、接住他人的场域。
这也是真人反馈为什么会比 AI 更留在我脑子里。
AI 可以给我一整屏很完整的结论，但它通常停留在“当下觉得有道理”。真人的一些话，信息密度未必更高，却会在两周后的具体场景里突然闪回。
比如，大鱼提醒我，我很容易给别人太多 content 作为前置信息。
这句话后来反复出现。无论是工作里解释一个问题，还是关系里试图让对方理解我的感受，我都会本能地想把背景、逻辑、证据、上下文一次性交给对方。我以为这是帮助对方理解，但它也可能是在把我的处理负荷转移给对方。
我过去很容易默认：只要我给得足够完整，对方就会更理解我。现在我开始多问一层：对方此刻真的需要这么多信息吗？他现在接得住吗？他需要的是材料，还是感受先被确认？
另一个反复闪回的是“标准外溢”。
我的完美、成就、行动、沟通、搜集、战略这些高位才干，在很多时候确实帮我把事情做快、做深、做完整。但它们也会在不知不觉中形成一种气场：即使我没有开口要求别人达到我的标准，别人也可能感受到压力。
这对我很重要。因为我过去会觉得，只要我没有明确要求别人，我就没有把标准强加给别人。但现在我开始意识到，人的影响不只发生在语言里，也发生在节奏里、边界里、默认期待里。
工作里的验证非常直接。
有一次对方其实只需要几个关键点和简单案例，我本能地顺着自己的标准做成了一套更完整的分析。事情没有坏，但它让我很清楚地看见：我习惯用 80 分的方式交付，而有些场景只需要 50 分。
“50 和 80 对最终结果可能没有本质差异”这句话，对我这两周的工作状态影响很大。它没有让我变敷衍，反而让我开始区分：什么是结果真正需要的质量，什么只是我为了安抚自己的完美主义而加上去的额外重量。
这背后还有一个更底层的责任边界。过去我会很容易把“我能控制的部分”扩张成“我应该负责的全部”。但很多工作场景里，真正有效的是把任务推进到当前系统需要的位置，而不是把它打磨到我自己心里的理想状态。
我也更能解释自己为什么有些任务启动很快，有些任务迟迟不开始。
当一件事有信息、有结构、有边界、有明确反馈，或者可以被拆成流程和 SOP，我的行动、搜集、战略、成就、完美会很快被点燃。我会进入一种近乎自动化的高效状态。
但这也提醒我，行动不等于稳定地长期推进。它更像一种很快进入现场、很快启动反应的能力。真正要练的不是一味更快，而是大鱼说的那种“慢快”：该快的时候快，该停下来等反馈、看边界、让事情自然发酵的时候，能慢得下来。
但当一件事反馈很慢、边界模糊、控制感低、很难判断做多少算够，我就会明显卡住。以前我可能只会责备自己拖延。现在我会先问：这件事没有满足我哪一种才干的启动条件？我是不是需要先补一个结构、补一个反馈点、补一个最低可交付边界？
这也是 AI 在咨询后的新位置。
它不再只是“帮我解释我是谁”，而是可以根据我的才干模式，帮我设计更适合自己的行动链条。比如先帮我把任务拆成可启动的步骤，设定 50 分交付线，标出哪些地方不值得过度完美，哪些地方需要用外部反馈补足低控制感。
某种意义上，盖洛普进入我的工作系统后，不是变成一堆需要背诵的标签，而是变成一个外置架构。它不一定每天占据我的主观记忆，但它会影响我怎么设计流程、怎么判断卡点、怎么处理 Plan-Fact Gap。
这件事也进入了我的 Life OS。
Daily 不再只是记录我有没有完成计划，而是帮我看见：计划和事实之间的差距，到底来自判断错误、睡眠和出行导致的身体容量变化、关系事件打断，还是默认反应链失控。关系维护也不再只是记录事件，而是更关注容量、节奏、隐私边界和对方能不能接住。甚至我对公开输出的理解，也从“把体验立刻资产化”，变成先确认它是否真的被现实调用过、是否有足够有效的反馈回路。
盖洛普给我的不是一个新的自我标签，而是一套更精细的自我观测仪表盘。
它让我看见，高位才干并不会自动等于优势。
行动让我能快速启动，也可能让我太急着进入执行。
搜集让我能建立丰富上下文，也可能让我给别人过量信息。
完美让我追求高标准，也可能让我不分场景地过度交付。
战略让我总想找到更优路径，也可能让我难以接受慢变量和低控制。
沟通让我擅长表达，也可能让我在关系里过度解释。
成就让我持续推进，也可能让我把休息和生活也变成待完成事项。
这些东西本身都不是问题。真正的问题是：我有没有看见它们正在启动？我有没有给它们合适的容器？我有没有在不适合的场景里，还继续让它们全功率运行？
这两周还有一个很大的变化，是我不再那么纠结“我和别人到底一样还是不一样”。
盖洛普让我看到，即使两个人达成了相似结果，背后的才干组合和反应路径也可能完全不同。有人靠稳定积累，有人靠战略判断，有人靠关系连接，有人靠高强度行动。结果相似，不代表路径相同。
这让我对“独特性”的理解变得松弛了一点。独特性不是一定要做出一个别人没见过的结果，而是我能不能看见自己如何自然地抵达那里，以及我是否愿意尊重这条路径。
所以如果要总结这次咨询对我的影响，我觉得不是“我更了解自己的优势了”这么简单。
更准确地说，是我开始学会在行为发生之前，看见那个准备自动反应的自己。
我开始能更早地识别：此刻我是不是又想把信息给全？是不是又想把 50 分任务做成 80 分？是不是又把自己的标准外溢给别人？是不是又把低反馈、低控制的任务解释成自己不够努力？是不是身体已经不在状态，但大脑还在要求系统继续运转？
接下来真正要练的，大概就是这些很朴素的事：
先判断场景需要 50 还是 80。
先确认对方需要感受、方向，还是材料。
先给高位才干一个边界，而不是让它们自动接管全场。
在低控制、低反馈的任务里，允许一个不完美但可推进的版本先出现。
在关系里，少一点“我把全部上下文都给你”，多一点“你现在能接住多少”。
在身体状态变化时，把执行力波动当作系统信号，而不是道德问题。
我现在也更能理解真人咨询的不可替代性了。
它不是因为 AI 不够聪明。恰恰相反，AI 已经很聪明，聪明到可以帮我搭建大量结构。但人的价值在于，他会出现在一个真实互动现场里，成为那个不完全按照我输入材料运转的他者。
AI 帮我把系统搭得更快，真人咨询让我开始看见，系统之外那个正在反应的人。
7 22
😮💨工作里真正耗精力的不是产出内容，是"翻译"内容——给领导适配成A版、给同事B适配成B版，每人都有自己的阅读格式和沟通协议，我就这样获取slack和notion上下文分析创建针对可以跟每个人接上的skill。
2 01
一直以为我妹没有太强接触 AI 的意愿，直到今天给我分享了一个小红书博主做的“给每个家具都配了一个人格”的视频，其实相当于定制化的 AI 软件+硬件+陪伴，于是趁她在我身边，说干就干，用豆包录制了小红书的逐字稿让 gpt 拆解并提供复刻规划，创建了项目文件夹，带着她用 codex 开发完了软件层面 mvp 并且把硬件准备加入购物车（这时意识到 xtool 其实非常适合这种场景，比如给每个家具做一个实体角色形象+AI 定制化灵魂），过程中她就非常直观地感受到神奇和快乐。
以及我也意识到要感染一个人快速接触并达到 aha moment 还得是线下直接 build 展示。
以及我也意识到要感染一个人快速接触并达到 aha moment 还得是线下直接 build 展示。
17 71
跟 @文森特别闹 交流后加深了对 cola 的理解，于是写了 5000+ 试图明确“Cola 是什么”
（在 claude和 chatgpt 外第一次大额美金消费：一次性花费 99 刀，加上前期的 20 刀怎么不算近千呢
（在 claude和 chatgpt 外第一次大额美金消费：一次性花费 99 刀，加上前期的 20 刀怎么不算近千呢
在一款AI产品上花费近千后，我开始怀疑人是否只能被人看见
5 33
我用 InsForge Storage 解决了邮件里图片不能直接 attach、copy-paste 又不稳定显示的问题。
背景很简单：我们要给达人发 creative brief，本来想在 Instantly 邮件里直接附上图片，或者把图片复制粘贴进正文。但实际测试下来，Instantly 更适合用 URL 插入图片，不太适合直接 attach 图片文件。copy-paste 进去的图片也可能因为邮件客户端、收件方系统或内嵌图片策略导致不显示。
所以我改成了一个更稳的方案：把 brief 图片上传到 InsForge 的公开 Storage bucket，然后在邮件里用图片 URL 引用。
具体做法：（全过程由Codex自行调用insforge cli实现）
1. 在 InsForge 项目里创建公开 bucket：public-images
2. 把本地 brief 图片上传到这个 bucket
3. 第一次用 CLI 上传后发现浏览器打开会下载，而不是直接显示
4. 排查后发现原因是 MIME 类型被记录成了 application/octet-stream
5. 于是改用 InsForge Storage REST API 重新上传，并显式设置 Content-Type: image/jpeg
6. 最后得到一个可以直接访问、也可以嵌入邮件的图片 URL
最终邮件里只需要这样插入：
<img src="图片URL" style="max-width:100%;height:auto;">
这样做的好处是：
- Instantly 不需要真正 attach 图片
- 邮件正文可以正常引用远程图片
- 图片地址由我们自己的 InsForge 项目托管，可控性更高
- 后续如果要替换图片，只要更新 Storage 里的文件即可
- 不依赖临时匿名图床，适合正式外联流程
这次的关键点不是“上传图片”本身，而是要确保上传后的响应头是 image/jpeg。否则浏览器和邮件客户端可能会把它当成文件下载，而不是图片展示。
结论：对于 Instantly 这类邮件系统，brief、banner、长图等素材不要依赖 copy-paste。更稳定的做法是：先上传到可公开访问的Storage，再用 URL 嵌入邮件正文。InsForge Storage 正好可以承担这个角色。
背景很简单：我们要给达人发 creative brief，本来想在 Instantly 邮件里直接附上图片，或者把图片复制粘贴进正文。但实际测试下来，Instantly 更适合用 URL 插入图片，不太适合直接 attach 图片文件。copy-paste 进去的图片也可能因为邮件客户端、收件方系统或内嵌图片策略导致不显示。
所以我改成了一个更稳的方案：把 brief 图片上传到 InsForge 的公开 Storage bucket，然后在邮件里用图片 URL 引用。
具体做法：（全过程由Codex自行调用insforge cli实现）
1. 在 InsForge 项目里创建公开 bucket：public-images
2. 把本地 brief 图片上传到这个 bucket
3. 第一次用 CLI 上传后发现浏览器打开会下载，而不是直接显示
4. 排查后发现原因是 MIME 类型被记录成了 application/octet-stream
5. 于是改用 InsForge Storage REST API 重新上传，并显式设置 Content-Type: image/jpeg
6. 最后得到一个可以直接访问、也可以嵌入邮件的图片 URL
最终邮件里只需要这样插入：
<img src="图片URL" style="max-width:100%;height:auto;">
这样做的好处是：
- Instantly 不需要真正 attach 图片
- 邮件正文可以正常引用远程图片
- 图片地址由我们自己的 InsForge 项目托管，可控性更高
- 后续如果要替换图片，只要更新 Storage 里的文件即可
- 不依赖临时匿名图床，适合正式外联流程
这次的关键点不是“上传图片”本身，而是要确保上传后的响应头是 image/jpeg。否则浏览器和邮件客户端可能会把它当成文件下载，而不是图片展示。
结论：对于 Instantly 这类邮件系统，brief、banner、长图等素材不要依赖 copy-paste。更稳定的做法是：先上传到可公开访问的Storage，再用 URL 嵌入邮件正文。InsForge Storage 正好可以承担这个角色。
4 00
