AI 方法论 · 一线实践

大多数人在用 AI 打补丁。 我在给 AI 做架构。

这一页写的不是「我会用哪些工具」。工具三个月换一轮，我今年 2 月做的那批智能体和 workflow，到 8 月基本已经不用了。不变的是你把 AI 放在什么位置上：让它替你出结果，还是让它在你定义的系统里跑。这两种用法产出的东西完全不同，我两种都试过，也吃过前一种的亏。

0分AI 直出的天花板
我实测下来的位置
80–90%AI 能替我省掉的精力
剩下的必须我判断
0层我给公司研发链路
搭的架构层数
0节点立项主链
已标准化并冻结
01 — 两种用法

打补丁，还是做架构。

这两个词是我们团队内部的叫法，用来区分两种截然不同的 AI 使用方式。很多人的低效不是因为模型不够强，是因为一直待在左边这一栏。

打补丁 · 常见用法

在一个很小的结果上反复修补

让 AI 写一段，看着不对，就告诉它「这里应该怎么写」。再看一段，再改一句。整个过程里 AI 始终不知道这件事的全貌是什么。

问题不在于改得慢。问题在于每一次修补的经验都不会累积，下一个任务重新开始，还得这么改一遍。

更糟的是你只能改你看得见的地方。AI 在你没注意的地方犯的结构性错误，会被一路带下去。

做架构 · 我现在的用法

先把顶层方法论定死，再让 AI 在框架里跑

不先让它写，先告诉它这件事到底要什么：用户是谁、终局是什么、判据有哪些、什么不能碰。方法论定下来之后，AI 的每一次产出都落在同一套标准上。

这样做前期明显更慢，要花时间把说不清楚的东西说清楚。但量产阶段的稳定性完全是另一个量级。

而且架构可以复用。这个项目定下来的判据，下个项目直接继承，不用从零开始教。

一个是直接把 AI 的东西当结果，一个是把 AI 当过程，这是完全不同的产出。
这句话是我在一次内部对齐里说的，现在是我团队的工作前提。
02 — 产出的性质

AI 的产出是工业品，
不是工艺品。

这是我判断一个人会不会用 AI 的第一个标准。如果还在用做工艺品的方式使唤 AI，那既拿不到工业品的规模，也拿不到工艺品的精细。

工艺品的逻辑是：一个手艺人，一件一件地雕，每一件都倾注注意力，做得慢但做得精。这是 AI 出现之前，做内容和做产品的默认方式。

工业品的逻辑完全不同：你不去雕每一件产品，你去设计那条产线。产线定义了标准、工序、检验点和废品处理，然后让它跑起来，产量和一致性同时出来。

AI 的产出属于后者。用手作的方式去使唤它，是两头不讨好：论精细，人自己做还更好；论规模，你被自己的注意力卡死了。它需要的是工程思维和架构思维。

这个判断有个很硬的支撑：所有 AI 底下都是代码，而代码思维和工程思维本来就是一回事。你在给 AI 设计工作方式的时候，做的是系统设计，不是文案指导。

落到我自己身上，最大的改变是：我不再花时间去改 AI 写的每一句话，我去改那套让它写出这句话的方法论。

改一次方法论，后面所有产出一起变好。这个杠杆是打补丁给不了的。

03 — 实际操作

AI 直出只到 70 分。
剩下那 20 分是这么来的。

上面两节是判断，这一节是我每天真实在做的动作。这条迭代链是我实测出来的位置，不是理论推的。

70
AI 直出
结构完整、看着像回事，一进真实业务就露馅。这是天花板，再怎么换提示词也上不去。
我改 10%
人的判断介入
我不重写，只动最关键的那 10%：判断错的地方、没抓住要害的地方。改动量很小，但改的是最贵的部分。
85
AI 基于改动再迭代
让它照我改过的方向把剩下的部分重做一遍。这一步 AI 学到的是我的判断标准，不是我的措辞。
90
再改 10% 收口
最后一轮人工收口。到这里我还会用另一个智能体去质检已经调好的顶层方法论，看它自洽不自洽。
AI 能省掉我 80–90% 的精力，但最有灵魂的那部分必须人来判断。
我的活不是写，是在 AI 的草稿上做取舍。这两件事需要的能力完全不同。

有件事得说清楚：关键不在于「人还要改」，在于「人改的是哪 10%」。如果你改的是措辞、语气、标点，那你只是在做校对，AI 下一次还犯同样的错。如果你改的是判断错的地方，AI 会把这个判断带到后面所有产出里。

这也是我认为 AI 时代最值钱的能力是判断力的原因。产出的成本被压到接近零之后，唯一还稀缺的是知道什么是好的。

04 — 从个人到组织

问答式调用，
和工程化协作。

上面三节都还是一个人怎么用 AI。真正难的是下一步：怎么让一个组织按系统运行，而不是每个人各自跟 AI 聊天。

问答式调用是现在绝大多数团队的状态：每个人都开着一个对话框，各问各的，各拿各的结果。表面上人人都在提效，实际上组织没有任何积累。今天张三问出来的好答案，明天李四还得重新问一遍。

工程化协作要求的东西多得多：上下文怎么传递、工具怎么统一、规则谁来定、改动之后怎么回归验证、证据留在哪里、过程能不能回读。这六件事共同决定结果，缺一件，系统就退回问答式。

我给自己的定位就在这里。我的优势不在于我能调用更强的模型，在于我能把业务判断变成可重复、可审计的协作系统。前者所有人都有，后者才是产品经理该干的事。

你把和 AI 的聊天记录发给我，我丢给我的 AI。
这是我们团队现在默认的同步方式，替掉了大部分进度会。沟通的最小单位，从「一场会议」变成了「一段可交接的上下文」。

这个动作看着只是省了开会时间，它改变的其实是协作的最小单位。以前交接一件事，要把背景重新组织成人能听懂的叙述，讲一遍、答疑一遍、对方再理解一遍，每一步都在折损。现在交接的是原始上下文本身，一次也不损耗。

这是我见过 AI 改变组织协作方式最直接的一个落点，而且它几乎零成本，只需要团队里所有人接受一件事：你和 AI 的对话过程，本身就是工作产物。

05 — 落地

我给公司搭的那套系统，
长这个样子。

上面讲的所有判断，最后都要落成一个真能跑的东西。这是我从 2026 年 7 月开始独立主导的公司级产品研发体系，四层架构，目前在运行。

第一层业务战略
这条业务到底服务谁、要成为什么、边界在哪。不解决这一层，下面全是白做。很多团队做 AI 改造直接从工具层开始，这是最常见的失败原因。
第二层业务设计
把战略拆成真实的业务流程与角色分工，明确哪些环节由人决定、哪些可以交给 AI，以及两者的交接点在哪。人机分权是在这一层定死的。
第三层节点标准
每个业务节点的单一事实源：交接物是什么、哪些参数不可擅改、来了新证据怎么触发变更、人工在这个节点的权力边界到哪。这一层是 AI 真正读的东西。
第四层技术承载
在飞书多维表格上落了五张全项目共用的运行表：项目配置、节点运行配置、依据绑定、批次、节点交付件。配三条规则：每个项目复制标准母版、新增表只能嵌套在标准结构里、母版的问题周会统一改，不许各项目自己分叉。

立项主链 · 六个节点

1.1信息源登记与核验
→
1.2优秀样本拆解
→
1.3产品方向研发与概念设计
→
1.4目录、Demo 与设计说明
→
1.5前端概念验证与迭代
→
1.6立项评审与决策
产品研发知识库的节点关系图谱 · 方法论、阶段 SOP、标准库与团队机制之间的引用关系
体系跑起来的样子。研发知识库的节点关系图谱：方法论、阶段 SOP、标准库、团队机制之间的引用关系。每个节点都能被追溯到它依据的标准。点开可放大看细节。

这六个节点原来是散在人脑子里的隐性流程，谁负责谁凭经验做。显性化、标准化之后，最大的变化是它可以被继承。新人接手不需要我口头讲一遍，AI 接手也不需要我重新描述背景。

我把这件事叫「让业务判断变成资产」。以前一个好的立项判断只存在于做那件事的人身上，人走了判断就没了。现在它是一条可回读、可追溯、下个项目能直接引用的规则。

06 — 验证

AI 最危险的地方不是产出慢，
是产出快到没人来得及验证。

体系搭起来之后，最先出现的问题不是没东西，是东西太多。所以我给团队定了三条标准，用来分清「做出来了」和「真的成了」。

生成 ≠ 采用

AI 写出来了，不代表有人决定用它。没有采用记录的产出，只是一个文件。

设计 ≠ 运行

方案设计完了，不代表它在真实业务里跑起来了。纸上的流程和跑着的流程是两个东西。

交付 ≠ 业务效果

交付了，不代表业务变好了。只有进入下一环节、且留下可回读证据的，才算业务结果。

这条规则最先卡住的是我自己。
我今年这套体系已经在跑，技术骨架也真建起来了。但我同时写了一份「当前不能对外宣称」的清单，跟成果清单一样长：不能说完整中台已经能跑、不能说 AI 已经会按业务标准判断内容质量、不能说这套东西已经降低了成本或提升了速度。这些都要等真实项目周期的数据。所以你在我的简历和这个网站上，都找不到「AI 提效多少」这句话。规则是我立的，我不能第一个破。
07 — 一句话

工具会换，
位置不会。

这一页从头到尾没有讲我用了哪个模型、哪个工具。因为那些东西半年就翻一遍，今年 2 月我做的那批智能体现在都不用了。

真正能带走的是位置：把顶层方法论定死，让 AI 在框架里量产，人守在判断和验证这两头。

这个位置换到任何一个业务、任何一代模型上都成立，这也是我认为一个 AI 产品经理该站的地方。

接着读《我的产品观》
判断权不能外包但必须接受验证 · 一个单品做到优秀仍然可能是零 · 立项前四问 · 有体系的好处是可归因 · 接手模糊任务的七个动作
读这一页 →