什么重要，什么不重要：AI Coding 落地里的 Intellectual Honesty

最近跟一家公司的团队聊了快两个小时，主题是 AI coding 到底怎么在公司里落地。老板在，开发、测试、产品都在，我在 Pure Global 的搭档 DJ 中途也上来了。

老板开场就讲了他们的困惑：几个月前，几个人扑在上面，想用 AI 把一个内部的 CRM 重写一遍，做了几个月，最后也没上线。他觉得“哪个地方有点问题”，但说不清是哪里。

聊完以后，我一直在回想那天会上的几种声音。它们几乎没有真正对上过。

团队问的是方法和工具。spec 文档应该写到什么粒度，需求用 Markdown 记录还是用原型图，有一个让 AI 反复追问需求的 skill 好不好用，端到端测试怎么用 AI 提效，硅谷那边的最佳实践是什么。

老板一直在插话。他说你们停留在旧时代了，做了这么多年，有谁敢说自己是这个系统的业务专家？你们问的都是肤浅的问题，工具的事情问 AI 就知道。

DJ 讲的是另一件事：工具每个月都在变，让 AI 帮你挑一个就完了；你真正该做的，是去找每天用这个系统的人，坐在他旁边，把他的工作变简单。

而我那天几乎只在重复一个问题：这件事到底谁说了算？

每个人说的都有道理。但我越回想越觉得，这几种声音之间的错位，基本就是很多公司 AI coding 落地失败的原因。工具问题、方法问题、心态问题都是真的，可它们都排在后面。排在最前面的那个问题，大家都在绕开：我们愿不愿意诚实地承认真正的问题是什么，然后有一个人站出来为它负责。

我把这件事叫做 intellectual honesty。翻成中文大概是“智识上的诚实”，说白了就是对自己诚实：承认我们其实不知道规则，承认这个东西本身就设计错了，承认这件事应该归我管。

这篇文章想讲清楚，在 AI coding 这件事上，什么重要，什么不重要。

“先假设他知道规则”

那天最让我印象深刻的，是一段关于报价系统的对话。

这家公司在用 AI 重构一个老系统，报价模块是缺陷最多的地方。折扣要反算，几个服务费之间要联动重算，一个参数改了，前端一串数字都要跟着变。开发晚上开一个 AI 线程把代码写完，测试那边却要花一到三天才能测完。提一个 bug，AI 改完，这三个字段对了，别的地方又冒出新的问题。

负责测试的同事问我：端到端测试用 AI 一直做不好，有没有什么技术方案？

我反问了一句：这个报价到底谁说了算？如果我是你们老板，觉得这个报价做得不对，想把一个人揍一顿，我应该去揍谁？是 PM，是开发，还是 QA？

这个问题没有人接。测试同事把话题拉了回来：“我们先假设他知道规则。假设大家都知道规则，怎么做测试？”

我说，问题就在这里，就是不知道。

这不是抬杠。如果所有规则都清楚，AI 一定能把测试做出来。一万条测试用例，每一条应该输出什么都说得清楚，你开一千台机器去跑，有什么跑不了的？技术上它只是一个花多少钱、开多少机器的问题。

真实的情况是，报价改了一个地方，系统像黑箱一样吐出一个奇怪的数字，没有人能马上判断这个数字对不对。于是每一个测出来的结果都像 bug，返工，再测，再返工。测试慢，是因为没有人知道正确答案长什么样。

其实就在几分钟前，团队自己已经说出了答案。开发负责人复盘的时候很坦诚：老系统是在一个开源的低代码平台上搭的，结构很乱，他们用 AI 把逻辑抽成了文档，但没有人逐个参数去溯源、去想新系统里该怎么做；需求阶段，产品、开发、测试也没有达成共识。他的原话是，“刚开始的时候，大家都想着走捷径”。基于一个不完整的东西去开发，反复是必然的。

这段话非常诚实。有意思的是，说完没多久，讨论又回到了“怎么用 AI 把端到端测试做快”上。

我后来想明白了，这不是哪一个人的问题。技术问题是安全的。问“怎么测得更快”，不需要任何人承认什么；问“这个报价体系是不是本身就设计错了”，就得有人站出来说：过去几个月的方向有问题，而且这件事归我管。

把最难的那部分假设掉，再去问一个技术问题，是我见过最常见、也最隐蔽的不诚实。没有人在撒谎，大家都很真诚，都在努力。只是所有的努力，都落在了不需要任何人负责的地方。

研究工具还有一个好处：它看起来很像进步。今天试了一个新框架，明天接了一个新 skill，周报里都有东西可写，也不会因此得罪任何人。我在《Happy AI Transformation》里写过，一家公司可以高高兴兴地做完一轮 AI 转型，核心业务却没有任何变化。放到一个团队、一个人身上也一样：你可以一直很忙、很投入地研究 AI，而那个真正卡住业务的东西，原封不动地待在那里。

实现已经不难了，难的是说清楚

那天我讲的第一个判断是：AI 时代，我们不再有难的实现问题，只有没想明白的业务问题。

很多人会对这句话点头，但不一定真的信。我讲一个我自己做的例子。

那次聊之前，我拿到一套很零散的东西，几十个代码库，有的有内容，有的是空的。他们的业务我也不熟。我按自己的理解，用 AI 重做了一个 BI 的 demo：跑在真实的数据库上，有报表，不同身份的人看到不同的东西，能看到表和数据模型之间的依赖，还有一个 AI 分析助手，你问它问题，它自己写 SQL、做推断、出看板。

这个助手背后，我故意用了一个能力偏弱的便宜模型。它依然能做对。

原因不在模型。原因在于我把大量时间花在了一件很琐碎的事情上：把定义写清楚。我管它叫口径。每一个口径都有编号、有理由、有测试，全部放在同一个代码库里；每张表、每个字段的 comment 都写得没有歧义。比如代码里有一个字段叫 internal plan，没有人能看懂这是什么，人看不懂，AI 也看不懂，只能猜。把它的意思写清楚，人和 AI 才能同时看懂。模型能做对，是因为它不用猜。

写这些口径的时候，我自己就卡在很多地方。比如人员饱和度：待审批的工时算不算？被退回的算不算？非项目工时算不算？一周跨了两个月，这周的工时算在哪个月？再比如一个职能团队的达成率，分母用内部计划、合同计划，还是别的什么计划？

这些问题看起来很小，但一张报表能不能对，全靠它们。我拿到的材料里写着“出一张表要 8 个月”。我不觉得这 8 个月是花在写代码上的，大概率是花在一轮又一轮地问“这个到底怎么算”上。

AI 写不对代码，大多数时候是因为我们自己描述不出来。一个指标的分母到底是什么，我们自己都说不清楚，AI 怎么可能明白？AI 是来实现我们自己想法的。想法本身是糊的，它实现出来的也只能是糊的。

这里有一个机制，我觉得很多团队还没意识到。

以前实现很贵。一个需求从文档到代码，要几天到几周，模糊的地方会在这个过程中被人慢慢消化掉：开发写到一半发现说不通，会回头去问产品；问不清楚，就按自己的理解做一个版本，再在评审里被慢慢磨平。慢，本身就是一种纠错机制，只是代价很高。

现在 AI 一晚上就能把代码写完。遇到模糊的地方，它不会停下来问你，它会挑一个看起来合理的解释，一口气写下去。于是所有没想清楚的地方，会在同一时间、以 bug 的形式堆到测试那里。

所以“开发很快，测试很慢”，根子并不在测试。测试是整条链路里第一个必须回答“正确答案是什么”的环节，前面所有没付的账，都在这里一起结算。你给测试换再好的工具，它结算的还是同一笔账。

这也是为什么我说，开发也好，测试也好，每一个人都必须能端到端讲清楚：一个数据是怎么从上游流进来的，每一步是怎么算的，最后为什么是这个数。以前你可以只管好自己那段接口，上游给什么我接什么，下游要什么我给什么。那个时代过去了。你自己不理解的东西，交给 AI 做出来就是错的。

所以在这样一套系统里，最重要的人，是那个负责口径、负责语义层的人。他不能说“我觉得这样可以，那样好像也行”，也不能一遇到问题就去问 PM 可不可以。他得能完全地说清楚：这个指标就是这么定义的，它跟业务是这么对应的，理由是什么，测试在哪里。这一层做好了，后面不管是人还是 AI 来做看板，谁都会做；这一层没人负责，后面的人工具再好，也只能猜。

这就引出了那天我问得最多的一个问题。

在这条 pipeline 里，谁是对的？

聊到开发和测试对不上的时候，团队是这么描述的：产品经理写好很完整的需求文档，开发用 AI 很快实现，测试拿到需求又自己理解一遍，再用 AI 去测，测出一堆差异，来回返工。他们问我，怎样才能做到 AI native 的整套开发流程，spec 应该包含哪些结构，要写到什么粒度。

我说这些都不重要，我只问一个问题：在整条 pipeline 里，谁是对的？是 PM 说的对，开发说的对，还是 QA 说的对？还是你们其实都不知道谁是对的？

回答是：“理论上应该是 PM 说的是对的。”

DJ 刚进会的时候就说过，没有 source of truth，就先把它立起来，否则不管怎么写，AI 怎么 debug、怎么 test，都会有问题。接着他问了几个很具体的问题。一个需求从进来到交付要多久？紧急的一周，不紧急的两周。每个需求谁负责？PM。PM 自己测不测？不测，只验收。一个 PM 管两个系统，每个系统十几到几十个客户，每天要回客户群里的问题，没有时间沉下来测。

DJ 说了一句我很认同的话：如果最终对需求负责的人不亲自测，他怎么有底气把这个东西交给客户？这个环节是脱节的。

团队里也有人提了一个很合理的反对意见：每个角色擅长的东西不一样。产品经理懂用户、懂交互，开发懂架构和技术选型，你不可能让产品经理去定技术栈。所以应该形成一套完整的协作流程：每个阶段由谁来定，怎么组织，最后大家达成一致。

我理解这个想法。它在过去是对的。

分工之所以存在，是因为每一段都很贵。写需求贵，写代码贵，测试也贵，一个人做不完，只能拆开，再靠文档和接口把它们串起来。代价是每一次交接都会丢信息，而且没有人对端到端的结果负责。以前我们接受这个代价，因为不拆就做不完。

AI 改变的是这笔账。代码的实现变简单了，需求文档的实现变简单了，测试的实现也变简单了。三段都便宜以后，剩下最贵的就是交接本身。一个需求在 PM、开发、QA 之间每被重新理解一次，就多出一个版本的“真相”。这些版本对不上的地方，就是他们每天在返工的东西。

拆的环节越多，最后反而没有人承担责任。PM 觉得写完文档就够了。够吗？他跟用户真的对齐了吗？跟实现出来的东西对齐了吗？开发觉得照着文档做就行，测试觉得照着用例测就行。每个人都尽了自己那一段的责任，整件事却没有人负责。

所以我的答案很简单：

这件事谁说了算，谁为这个结果负责，谁说的东西是对的，就让这个人去做。

工程师不能写文档吗？工程师不能做 QA 吗？这个人是 PM、是工程师还是 QA，甚至有没有这些角色，都不重要。我们给他最好的工具，让他把事情做好，其他人听他的。

马上有人追问：那这个人在哪个环节产生，怎么产生？

我说那就看老板支不支持了。你今天跟老板说：这个项目我全权负责，做好了是我的，做差了全是我的事，所有人都听我的，我完全理解这个业务流程。如果我下面有人这么跟我说，我肯定让他放手去干。

后来又有人问，你们在美国是怎么组织 AI native 开发的，从需求到文档到开发，有什么样的流程？我的回答还是同一件事：让更少的人，拥有更大的权限。你看到的越 AI native 的公司，一个人 own 的东西越多，他同时推进的东西也越多。

DJ 讲了他自己的一个例子。他们在泰国有一个子公司，进出口的流程很复杂。他飞过去，跟那边的团队坐了两天，听他们一步一步讲流程，第二天就把整个流程的程序写出来了。写完他也没急着交给团队，自己又测了一周左右，直到他觉得“如果我是他们，我会用这个东西”。

这就是一个人说了算的样子。没有需求文档在三个角色之间流转，没有“理论上谁是对的”。懂业务的人离业务最近，中间传话的人越少越好。

老板说对了一半

那天老板插了很多次话，而且几乎每一次都在支持我。

他说你们做了那么多年，有谁能站出来说自己就是这个系统的业务专家？你们总觉得业务是产品经理的事、是别人的事。如果还觉得“我后端写得好，我前端写得好”，那个时代已经过去了，AI 比你厉害多了。后来他又说，你们总想知道用什么方法、什么工具，这其实是一个肤浅的问题，不懂就问 AI。

他还做了一件很对的事。讨论一度停在“开发不准、测试不准”这种泛泛的描述上，是他打断大家，要求拿一个具体的案例出来。报价系统就是这么被摆到桌面上的。没有这个案例，那天的讨论很可能一直在空转。

他说的大部分我都同意。但我觉得他只说对了一半。

他的诊断是：问题出在人身上，大家的能力和心态还停在旧时代，每个人都应该成为领域专家。这没错。可一个人真的成了报价系统的专家，然后呢？他能决定把报价体系改简单吗？他能跟销售说“这种定制我们以后不做了”吗？他能拍板说老系统不要了，我们重写吗？

如果这些他都决定不了，他再懂业务，也只能继续在一个不可维护的系统上测试、返工、解释。他会变成一个非常懂业务、也非常痛苦的测试。

所以 ownership 有两面。一面是个人的：你愿不愿意去理解端到端的业务，愿不愿意站出来说“这件事归我”。另一面是组织的：老板愿不愿意把决定权真的交出去，包括改掉老板自己当年拍板的那些东西的权力。

如果我是老板，我会做的第一件事，不是要求每个人都变成专家，而是先挑一个系统，比如这个报价，指定一个人，跟他说：从今天起这个归你，改价格体系、砍定制、重写，你说了算，结果你负责。专家是在这种位置上长出来的。

我在《AI 杀死了我容忍弱智的能力》里写过，很多聪明人在系统里待久了，会把自己改变不了流程、改变不了组织的无力感，变成对某个人的抱怨。员工抱怨 AI 不准，老板抱怨员工不动脑子，在我看来是同一件事：问题被归到了某个人头上，而那个“谁说了算”的结构一点都没动。

诚实对两边都有要求。员工要承认“我们其实不知道规则”，老板要承认“我们其实没让任何人能拍板”。

敢说“这个东西本身就不该存在”

回到报价系统。

测试同事后来问得更具体：报价系统各个产品之间本来就有很多依赖，参数之间也有依赖，假设有一万条测试用例，分别对应不同的测试路径，怎么快速端到端地把问题筛出来？

我当时说，回答这个问题让我觉得很痛苦。这是一个很技术的问题，你今天去问 AI，它就会给你一个答案。但我想告诉你的是，这个问题不是真正的问题。

真正的问题是，我们为什么允许这么复杂的一个东西存在？客户看不懂，自己团队维护不了，测试测不完。这不是 QA 的问题，是一个系统性的问题。如果有一个人真的在乎这个报价系统，他看到它现在的样子，第一反应应该是：这个东西压根不可能维护，我要把它改成一个更简单的报价体系。

但没有人做这个决定。PM 不做，开发不做，QA 也不做。于是所有人围着一个不可维护的东西，研究怎么让机器把它测完。好像只要 AI 足够强，总会有一个魔法一样的 AI，能理解我们自己都理解不了的东西，然后帮我们把问题解决掉。

不会有的。如果借助了这么多 AI，我们还是没有一个人能完全理解这个报价系统，那就只能回去改报价系统。

DJ 那天说得更直接：报价这个东西，本质上就是数据加固定的公式。每个服务有价格，定制的部分有定制的规则；公式是确定的，输入 A、B、C，输出就是那个数，它不是一个概率问题。把数据和公式理清楚，让 AI 帮你重新做一个，可能比在老系统上修修补补还简单。

我们在 Pure Global 就是这么做的。原来的报价体系也很复杂，后来我们觉得它不可维护，就全部改成了一个最简单的版本，价格也全变了。不只是报价，我们所有的系统都重写了。

这个世界上绝大多数需求是不对的。把它们理清楚、做得可维护，对客户好，对我们自己也好，这才是我们真正的价值。

这个判断也适用于客户的定制需求。那天还有一个问题是关于 BI 权限的：客户要在一个独立的系统里自己配权限，角色没法预先定义，团队只能在 SQL 里塞各种自定义参数来控制谁能看到什么。我的看法是，客户提了需求，不代表我们一定要无限满足。用好数据库原生的权限能力，有限地支持，能覆盖百分之九十甚至九十五的需求。剩下那些真正奇奇怪怪的定制，尽量剥离出去单独处理。它很烂，就让它自己烂去，别让它污染核心的设计。

很多系统已经到了这样一个程度：不断加工具、加补丁，只会让它越来越复杂，复杂到所有开发都推不动。这时候靠优化已经解决不了问题，只能重写。重写本身也没那么神秘。用 ETL 把上游的脏数据挡在外面，大部分时间花在把脏数据整理干净上；内部只维护一个设计得很好的核心数据层；一个东西只有一个代码库；数据量本来就不大，一个 Postgres 加 serverless 就够了，不需要 Kubernetes，也不需要再加新的工具。

这些技术决定都不难。难的是有人敢说出“我们只用一个数据库”“这个报价体系要推倒”这种话，并且为它负责。这种决定一旦做了，后面所有围绕它的开发都会变简单。

什么不重要

说到这里，可以回答标题的另一半了。

那天被问到的很多问题，我都觉得不重要。它们并非毫无价值，只是答案很便宜，随时可以拿到，也随时会过期：

• 用哪个 spec 框架，文档写到什么粒度。能让 AI 把东西做对的粒度，就是对的粒度。
• 需求用 Markdown 还是原型图。Markdown 可能够用，HTML 也可能够用。不同的 AI 生成的文档，用词都不一样，最后还是得有一个人来判断够不够用。
• 某个 skill 好不好用。我自己不喜欢那类让 AI 反复追问需求的 skill，但这不代表你不该用。你完全可以同时让 PM 试十个 skill，回头看哪个效果最好。
• 端到端测试用什么工具。今天告诉你工具 A，下个月就有更好的 B 和 C。
• 硅谷的最佳实践。

最后这一条我想多说两句。团队里有人说，“我们也不是不会用，是用了效果不好，也没有最佳实践”，所以想看看硅谷的大佬们是怎么做的。

我很理解这种想法，但它背后藏着一个假设：存在一个我知道、你不知道的秘密。现在没有这样的秘密了。信息是透明的，你用的 AI 跟我用的 AI 是一样的。任何一个好的 best practice 出来，AI 很快就会知道，而且可能比你想的还要前沿。我在《AI 时代的真优先级》里写过，关于 AI 声音最大的地方，往往离真实的闭环最远。出去找“最佳实践”，很多时候就是走到了声音最大的地方。

DJ 的做法很简单。工具的问题，他直接让 AI 评估一下，AI 觉得现在哪个最好就用哪个，下个月有了新答案，再升级一版。我们已经很久不在会上讨论工具选型了。

那测试慢的问题，是不是就不管了？也不是。如果它真的是 blocker，我的建议是让团队里最聪明、能力最强的工程师，跟 QA 坐在一起，花几天到一周，帮他把提效的工具做出来。这件事我帮不了，DJ 也帮不了，只有他们自己团队里真正在乎这个问题的人能做。

工具今天很便宜，便宜到可以同时试十个。贵的是那个能判断“试完到底有没有用”的人。每一个关于工具的问题，追到最后都会回到同一个地方：你们团队里，谁来说这个东西有用？

把权力交给一个人，安全吗？

讲到“让一个人说了算”，团队里有人提了一个很实际的担心：如果所有东西都是一个人跟 AI 讨论出来的，那知识不就都在他一个人的脑子里，或者在某个 AI 会话的上下文里吗？账号被封了怎么办？上下文丢了怎么办？换一个人来怎么接？

这个担心是对的，但它把两件事混在了一起：决定权集中，和知识集中。

决定权应该集中。知识绝对不能集中在一个人的脑子里，也不能只留在某个 AI 会话里。我的要求是，一个东西只维护一个代码库，前端、后端、数据、口径全部在里面。所有定义都有编号、有理由、有测试，有版本记录，你能看到它每一次怎么变的、为什么变。理想的状态是，把这个代码库发给一个完全不懂的外人，他就能看明白你们在做什么。

我自己做个人网站的知识库也是同一个原则：source of truth 必须落在 AI 和人都能读的地方，不能只在我的记忆里。

所以集中决定权，并不会让组织更脆弱。现在这种分工方式反而更脆弱：需求在 PM 的文档里，逻辑在开发的脑子里，规则在测试的用例里，三份东西互相对不上，哪一个人走了，都会留下一个没人能解释的黑洞。

还有一个边界我也想说清楚。我并不是说所有复杂的业务都能简化成几个公式，也不是说每个系统都应该推倒重写。有些复杂是真实存在的：监管要求、多国家多语言、历史合同。重写也有成本，要有人判断值不值得。我想说的是，这些判断本身就是 owner 的工作。一个真正在乎的人，会分清楚哪些复杂是业务本来就有的，哪些是我们自己一层一层堆出来的。前一种要认真设计，后一种要有勇气删掉。

诚实，然后有勇气重写

回到开头那个没上线的 CRM。我没有看过那个项目，不知道它具体卡在哪里。但听完那天的讨论，我大概能猜到它是怎么卡住的：几个人用 AI 很快把代码写了出来，然后在一轮又一轮的“这个到底对不对”里耗掉了几个月。如果真是这样，换一套工具再来一遍，结果也不会有什么不同。要换的是另一件事：先找到一个人，让他把这个系统要做成什么样说清楚，并且为它负责。

那天最后，我说了一段话，大意是这样的。

AI 时代，大家要诚实，要去解决公司真正最重要的问题。我相信每个在这里工作的人，心里都知道自己公司真正难的问题是什么，要怎么解决。只是有没有这个勇气说出来，有没有这个勇气去重写。

很多时候，你知道问题是什么，但你不敢说。你担心说出来会影响到谁，会碰到谁的东西。于是屎山越积越多，最后大家双手一摊：这也不是我的责任。

那个时代过去了。以前不说，还有一个说得过去的理由：就算说了也改不动，重写一个系统要一个团队干一年，谁也担不起。今天这个理由不成立了。DJ 那天说，Pure Global 在高峰期，国内有二十来个开发，现在开发基本就是我们两个人，主要是我一个。把 AI 用好，一个人顶十个、二十个人，是真的。

重写的成本已经变了。真正挡在前面的，只剩下我们愿不愿意承认问题。

今天公司和公司之间的区别，就在于有没有人看见问题、说出问题，然后为它负责。

我在那天的最后说了两遍：所有的问题都能解决。

前提是，先承认它是个问题。