上一篇我写 AI 在复杂 2B 场景里到底该接到哪里--关于AI在复杂ToB项目场景应用的初步思考。那篇更像在画地图。我把一条内部工作链拆开了，从原始捕获、上下文理解、质量判别，一路走到场景归类、旅程洞察和流程协同蓝图。

写完之后，我也沿着这个方式想继续做下去，有一些收获，也有一些新的感想，便想写下来做一个分享。

为什么我先做的是 skill

最近我做了两个和我日常工作比较相关的 skill。

一个是会议纪要。

一个是 PRD 校验。

它们看着都像 AI 写文档。你把转写或者文档丢进去，它给你吐一份像样的东西出来。很多人看到这儿就会下结论，哦，都是文档生成。

肯定也有人会问，为什么不直接做 agent，现在 agent 这么火，为什么不直接把这两件事都往 agent 上靠，或者干脆套一个对外更好讲的说法。

我自己现在的判断是这样的。

对于很多确定性很强的事情，更应该优先用 skill 或者 workflow 来实现。因为这类事情的目标清楚，输入相对稳定，评判标准也能提前说清楚。你真正需要的，不是一个一直临场发挥的东西，而是一套能稳定复用的做法。

而创造这些 skill 或者 workflow 的过程，反而可以大量借助 Claude、Codex 这一类 agent。它们更适合拿来探索路径、补工程细节、不断试错，直到把一个原来只存在于脑子里的做法，沉淀成可复用的结构。

只有那种没法提前规划好每一步，要一路根据环境反馈调整策略，最后才能到目标的任务，我才更愿意把它交给 agent 去跑。

所以这篇文章里我想聊的，不只是我做了两个小东西。

而是我为什么会觉得，这两个东西更适合先长成 skill 和 workflow，而不是先长成一个什么都能干的 agent。

会议纪要真正难的不是成稿

先说会议纪要。

会议纪要这件事，听起来可能是最简单的。现在很多会议软件自己就能生成纪要，拿到转写再扔给一个模型，也能直接出一版。

如果只是做表层评价，标准好像也很直接。写得像不像人，有没有明显的转写错误，特定场景的术语识别是否正确，发言人标签能不能尽量对上。

但这些其实都还是表层。

通过更好的模型、一些标签、一个小术语库，很多问题都能缓解。真正难的，是另一层东西。

为什么要开这场会。

这场会在整个项目进程里起到了什么作用。

它承接了什么历史背景。

它又会把什么判断传到下一轮设计和执行里。

一旦问题落到这儿，事情就完全不是把转写整理通顺那么简单了。

今天的一场会，往往接着上周那场专题。上周那场专题，又接着更早的一轮争议。你如果只是把当场转写扔给模型，让它整理一份会议记录，它当然也能生成，但那个东西大概率只是一个干净一点的摘要，不像一个能继续进入项目链路的管理文档。

所以我后面在会议纪要里花力气的地方，反而都不在文风本身。

是需要把超长文本先做分段摘要。

把项目背景、风格样本、上次会议延续信息一起塞进去。

议题也会单独沉下来，让后面几场会知道这次到底在承接什么。

如果同一类说法、同一类判断、同一个争议点在不同会议里反复出现，它就不该只在某一篇纪要里出现一次，然后消失。

这时候你再看，它做的就不是写一篇纪要了，而是在稳定生产一类文档，而且这个系统会越来越懂这个项目自己的词汇、上下文和组织语气。

更关键的是，它的输出目标也变了。

我后来专门要求这套 prompt 别写流水账，别只记这场会谁说了什么，要去抓领导意图、认知纠偏、协同关系，还有会后谁该动、怎么动。

因为工业项目里最值钱的读者，很多时候不是参会的人，而是没参会但后面要接着干活的人。你给他一篇流水账，他还是不知道为什么这么改。你把管理意图和调整方向接住了，他拿过去就能继续往下推。

这件事落在我手里的几个成品上，感觉特别明显。有些纪要写完之后，你会觉得这不像一篇摘要，更像一个临时搭起来的管理接口。会议上的判断没有散掉，后面的人能顺着这份文档继续工作。这种感觉，和单纯写得顺不顺，已经不是一个层面的满足了。

当然，它也远没到可以拍胸脯的时候。

它现在还是很依赖大 prompt 去悟。有些最值钱的内容，比如管理意图反馈和认知纠偏，很多时候还是模型从上下文里自己体会出来的。体会对了，很爽。体会歪了，也挺要命。

而且再往下走，你会碰到一个更麻烦的问题。

钢铁行业有哪些应该默认存在的背景知识。

各工序衔接管理的组织逻辑关系是什么。

哪些口径在项目组内部已经是默认前提。

哪些角色虽然没在这一场会里明确说出来，但其实一直在背后影响判断。

这些对人来说往往是常识，对模型来说却都是未知项，而且很难靠几句补充说明一次性讲清楚。

再往前走，还会碰到另一层问题。

多个会议的交集应该多久去汇总一次，形成新的网状知识结构。

哪些摇摆的决策在反复横跳。

各部门实际执行的结果，和会议里说的到底是不是一回事。

这些如果接不上，它就还是一个会写文档的系统，还不是一个真能推动协同的系统。

所以会议纪要这条线，我现在的判断很明确。

它最难的不是成稿。

而是输入治理、上下文承接、行业默认知识补充、跨会议沉淀，以及最后有没有能力把这些东西继续往协同里推。

PRD 校验真正做的是质量收口

再说 PRD 校验。

PRD 校验这条线，和会议纪要很不一样。会议纪要更像是在把现场接住，PRD 校验更像是在正式设计成文之后，再做一次质量收口。

它要回答的不是文档写得顺不顺。

而是前面这些管理思路、场景判断、协同要求，到了正式设计文档里，到底有没有被贯彻进去。

所以我做 PRD 校验时，第一步不是去看字多不多，图全不全，而是先判断这到底是什么类型的文档。它是不是内部系统，是从 0 到 1 还是模块迭代，是业务型管理系统还是偏工具、偏平台，有没有 AI 能力设计。这些前提不先定，后面的审查方向就不好确定。内部系统和 SaaS 看法不一样，模块迭代和新系统不一样，带 AI 的设计和传统业务系统也不一样。虽然我定的标准不一定完全对，但总归得先有个方向。

等这个前提立住，后面我主要看三层东西。

第一层，看业务意图是否清晰。前面的会议纪要、调研结论、管理要求，到了 PRD 里是不是还成立。有没有出现会议上已经说得很清楚，文档里却写偏了的情况。有没有为了让文档更完整，把真正的管理目标写散了，或者换成了一套听上去更好看、实际上更偏离的说法。

第二层，看设计架构是否清晰。核心对象有没有建模，状态机有没有讲清，跨角色主流程有没有闭环，数据来源规则有没有说清，权限、异常、回退、锁定、确认这些关键动作有没有落细。复杂 2B 后面真正容易炸的，通常都不是页面不够多，而是这些架构散乱拓展性差。

第三层，看这份文档有没有进入可交付状态。也就是它除了能拿来讨论，还能不能拿来推进。有没有优先级、问题分级、上线治理、培训支持、复盘节奏这些东西。它到底只是一个看起来完整的设计稿，还是已经能支撑后面的开发、联调、评审和上线。

这也是为什么我会逼着它按正式评审的方式来。不是泛泛聊几句建议，而是尽量把问题钉在正式评审应有的位置上。什么是 P0，什么是 P1，哪些问题不先补，后面整条链都会受影响，哪些问题可以暂时放一放。

正好就最近有一份比较大的文档需要审阅我就测试了一下。我自己最直观的感受就是，这件事一旦做对了，它就不再是帮我看看文档，而是在替我提前做一次高强度的质量把关。你最后拿到的，不是一堆泛泛的意见，而是一份可以继续往下推进的正式审查结果。

上一篇里我提过，AI 一旦把初稿生成这件事前置了，组织里最稀缺的东西就会开始往评审、判断、取舍和质量把关上集中。PRD 校验踩中的，其实就是这个位置。很多前序没有想清楚的、和业务意图有悖的，或者看起来写得完整、其实根本没法落地的内容，都可以在这一步被提前校验出来。

最后想说的

因为一旦这条链真正转起来，项目会被看得更清楚，方案会被做得更扎实，经验也会更稳定地沉淀下来。

这可能才是复杂 2B 里，最值得长期做下去的东西。

最后有想投稿的也可以后台联系哦～我已经跑通了文章自动发布的流程嘿嘿～