写给 Agent 应用工程师。案例是这个仓库的
docs/runbook/：一条自动抄录与 Claude Code 的每一轮交互、再提炼成三份签入文档的管线。这篇讲三件事：它值在哪、怎么做的、以及 那份「提炼契约」里有哪些可以直接抄走的规矩。
这套 runbook 最大的价值不是「有了历史记录」—— 那部分靠会话 transcript 本来就有， 不用额外做任何事。它干的是一件更特殊的活：把「为什么现在的代码是现在这样」从某个 人的脑子里搬到版本库里，并且用机器去逼它对齐提交历史。
CLAUDE.md 自己写着这条链路的痛苦：「改动前先知道为什么是现在这样，否则很容易改回去」。
这个仓库改回去的代价特别高 —— 它有一串静默失败模式：eval 的 answer 闸门一旦放宽，
分数一夜之间虚高接近满分；泄漏闸门漏扫中文路径，整片文档静默地不在检查范围内；
--flatten 丢一个标记位，防自环就失效。每一条都是「当时为什么这么写」一旦丢了，
就会被「顺手改回正常」重新放出来的东西。而这些为什么大概率不在代码里，也不在任何
issue 里。
这周二，我开了一场 AI 钉钉的战略沟通会。
会开完了，按惯例，事情应该到此为止——大家听完、散场、各自回去干活。但这一次我盯着会后那张评估问卷的回收数据，突然意识到一件事：这场会从头到尾，没有一个环节是「用完就扔」的。
HR 在会前一周就用 AI 表格收集了同学们的问题，其中大家最关心的是千问办公和钉钉的关系；我基于这些真实问题，用千问办公读我的个人 wiki，生成了一份沟通会叙述稿，自己调整之后做成 PPT；会后，HR 又用千问办公加 AI 表格技能，基于沟通内容生成了一张调研问卷，回收数据，再用千问办公对整场会的效果做了评估。
一场内部沟通会的完整生命周期——从「同学们关心什么」到「这场会到底有没有效」——全部跑在 AI 工具上，而且每一环的输出都是下一环的输入。
我觉得这很 AI native。但真正让我停下来想的，不是用了多少工具，而是另一个问题： 一场会开完，它留下的东西，到底是资产还是损耗？
YC Startup School 的舞台上，主持人 Diana Hu 问 Jeff Dean 一个问题。在此之前，Dean 刚讲了他和搭档 Sanjay 写的一个性能优化 Skill——教模型自己做「跑 benchmark → 改代码 → 测提升 → 再迭代」的闭环。Diana 听完说：「如果谁拿到这个 Skill，就能像 Jeff Dean 一样做性能优化了。这东西肯定价值无限。有人能拿到它吗？」
Jeff Dean 的回答出乎所有人意料：「哦，我们其实把它公开了。」
他说的是他和 Sanjay 合写的一份 30 页文档，叫 《Performance Hints》。后面还有一个细节：有人把这份文档做了摘要，喂给不同的模型，发现模型在性能问题上的推理能力真的变强了。
全世界都想要的东西，他直接公开了。这一幕值得多看两眼——因为它指向一个被严重低估的变化： 组织里最值钱的知识，载体正在从「写给人读的文档」悄悄换成「写给 Agent 执行的 Skill」。
老周是我们团队最资深的售前。上个月给华东一家汽配连锁分销商做方案，他熬了三个通宵，产出一份 80 页的 PPT —— 行业洞察、痛点拆解、架构图、ROI 测算、三个同行的成功案例，一应俱全。客户的财务总监当场说：「这是我见过最懂我们的方案。」单子签了。
四个月后，这个客户在续约评估里打了低分。原因不是产品不好，而是交付团队上线的对账流程，跟老周方案里承诺的「月结 T+1 出报告」对不上 —— 交付的同事根本没看过那份 PPT，他们手里只有一个工单：「给客户 A 部署对账 Agent」。老周写进方案的服务标准，卡在了销售和交付之间那道看不见的缝里。
而那份被财务总监称赞过的 80 页方案，此刻正安静地躺在某个钉盘文件夹里，再没有人打开过。
周三晚上 9 点，供应链主管小林在钉钉里收到一条告警：「供应商 A 本周交货延迟率从 3% 升至 12%」。他看了一眼，回了句「知道了，季节性波动，不用管」。这条消息随即被淹没在后续 200 条群聊里。
两个月后，另一个团队的采购经理在审批供应商 A 的新合同时，完全不知道这段历史。合同正常通过。三个月后，供应商 A 果然出了大问题——产能不足导致全线延迟。
这个故事里， 信息是存在的——告警推了，人判断了，反馈也有了。但信息在人与人之间断裂了。小林的处理经验没有被结构化地沉淀下来，后来的决策者无从获取。
这正是大多数企业 AI 落地时撞上的第一堵墙： 不是 AI 不够聪明，而是企业的「神经系统」还没建好。
上周五，我让 AI 帮我分析一场 90 分钟产品周会的听记转写稿——15000 字的会议记录，要求提取关键决策、未闭环的行动项、以及和过去三个月决策之间的矛盾。
第一次，我直接把转写稿喂给 AI，说「帮我整理会议纪要」。得到一份「看起来还行」的摘要：谁说了什么、讨论了什么话题。但这不是我需要的——我需要的是 洞察。
比如：技术负责人在讨论方案 A 时说「我觉得可以上」，但架构师追问了三个问题后，他改口说「那还是再看看」。AI 的摘要写的是「张总介绍了技术方案」—— 关键决策点被淹没了。
[Read More]上周我打开了尘封已久的 Obsidian vault。
50 多个插件，300 多个标签，12 个 database view，还有一套精心设计的 MOC（Map of Content）索引系统。我花了不知道多少小时在「组织」知识，而不是「使用」知识。
然后我意识到： 这套系统在 AI 时代已经过时了。
[Read More]上周五晚上，我让 AI 帮我做一件事：把过去三个月收集的 47 篇关于 Agent 架构的文章、12 段会议笔记、和 6 个项目的 README，整理成一份「哪些架构模式真正有效」的判断。
如果是一年前，我会得到一份按关键词频率排列的摘要——看起来专业，实际上没用。
但这次不同。AI 花了大约 40 秒，输出了一份结构清晰的报告：哪些模式在多个项目中反复出现、哪些只在特定场景下有效、我的笔记里对同一问题有过矛盾的判断。它甚至指出了我在三月份写的一段话和五月份的一个项目决策之间的矛盾。
这不是搜索，不是摘要，不是 RAG 的简单检索。这是 理解。
知识管理有四个值得做的企业场景，其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。
但如果你换一个角度看，SOP 沉淀的真正价值不是「把经验存起来」，而是 把经验变成可执行的系统行为。
这篇文章用一个完整案例来说明：一位 Windows 用户打开悟空发起任务，悟空报错「任务执行环境准备失败」，到 AI 定位根因、修复代码、验证、发布，全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。
[Read More]你花了两周时间，终于摸索出了一套让悟空写技术方案「一次可用」的 Prompt 组合：包含提问澄清、交付物定义、示例对齐和工具调度。你觉得自己简直是 AI 协作大师。
但当你把这套方法推荐给团队时，发现大家根本用不起来。
个人用得好，不等于团队用得好。
在前面的七篇文章中，我们构建了从 需求澄清、分步执行、交付物定义、示例对齐、迭代优化、上下文管理 到 工具协同 的完整个人技巧体系。
但这些技巧如果只停留在你的大脑或剪贴板里，它们就是易失的、碎片化的、不可复用的。
今天，我们探讨技巧八：如何通过「提示词工程化」，把个人经验沉淀为参数化模板和团队 SOP，实现 AI 协作的工业化生产。
[Read More]