把 AI 当员工管：不写代码的人如何对 AI 交付的结果负责

把 AI 当员工管：不会写代码的人，怎样对交付结果负责

AI 可以补上工程实现能力，但不能替你定义问题、划定边界和验收结果。

上一篇把六个岗位摆上桌，比较谁离领域型 FDE 最近。最后的结论是：售前离得最近，因为他最硬的一块缺口是工程实现，而这块恰好正在被 AI 补上。

这句话很容易让人兴奋，也很容易让人误会。

AI 能补上工程实现，不等于对着它说一句话，第二天就能拿到一个生产系统。更不等于从此不需要测试、不需要评审、不需要为结果负责。

我收到过两种很典型的反馈。一种是：「你们这些能用 AI 做系统的都是大牛，我肯定不行。」另一种是：「我试过，写出来的东西根本不能用。」

一个把 AI 抬得太高，一个把它压得太低。最后得到的结论却一样：我还是不要动手了。

这篇文章不讲怎么选工具，也不教一条所谓的万能提示词。我只想把一件事说清楚：在边界清楚、结果可以验证、风险可以控制的任务里，AI 已经能够承担大量工程实现工作。不会写代码的人也可以主导这个过程，但不能退出问题定义、风险裁决和结果验收。

一、先说清楚，什么叫「可以交付」

很多人把软件开发理解成写代码。于是问题就变成了：我不会写代码，怎么可能做出一个系统？

可真正做过企业项目的人都知道，代码能跑，只是很靠前的一步。

一个东西要交到用户手里，至少要过几道关：功能是不是对的，环境里能不能部署，出了问题能不能查，改完以后会不会把别的地方弄坏，后面还有没有人接得住。涉及权限、资金、生产控制时，还要回答风险能不能接受、出了事能不能回滚。

所以，「写出了代码」和「完成了交付」之间，隔着测试、部署、验证、维护和风险控制。

AI 现在最擅长补上的，是中间那段工程实现。需求相对明确时，它可以搭前后端、连数据库和 API、写测试、查报错、补文档，也可以根据反馈一轮一轮地改。过去需要排进研发计划、等上几周的小工具，现在常常几天就能看到一个可以运行的版本。

但另外一些事情并没有因此消失：到底要解决什么问题，哪些功能现在不做，什么结果才算正确，哪些风险不能碰，什么时候可以上线。

AI 降低的是「把方案做出来」的成本，没有消除「判断它做得对不对」的责任。

二、AI 能不能做出可交付代码，要看三个条件

我的判断是：在大量常见的企业应用里，可以。比如内部查询工具、数据清洗、报表和可视化、小型业务系统、API 集成、只读分析页面，这些任务已经很适合由人带着 AI 完成。

但这个判断有三个前提。

第一，边界要相对清楚。

你至少要能说清楚，这个东西给谁用，要解决什么问题，输入和输出是什么，和哪些系统连接，哪些内容这次先不做。

如果需求只有一句「帮我建设一个数据安全平台」，人都不知道终点在哪里，AI 只会替你把空白补成一份看起来很完整的方案。反过来，如果任务是「把研发设计文件异常外发事件的调查时间压到十五分钟，并保留身份、密级、路径和处置结果」，它就知道该围绕什么工作，也知道最后拿什么验收。

第二，结果要能够验证。

页面应该出现什么，接口应该返回什么，数据处理前后应该发生什么变化，哪些测试必须通过，哪些异常必须被拦住。这些问题越明确，AI 越容易被管住。

如果一件事做得对不对，连你自己都说不清，就不能指望 AI 替你完成验收。

第三，风险要能够控制。

第一次用 AI 做工程，不适合从最危险的地方开始。内部工具、只读查询、可回滚的小系统，做坏了可以改，可以重来。身份认证、资金交易、核心生产控制、不可逆的数据修改，则需要更严格的测试和专业评审。

这不是 AI 行不行的问题，是不同任务本来就应该有不同的门槛。

不是所有代码都适合直接交给 AI，但适合由人带着 AI 完成的范围，已经远大于多数人的想象。

三、AI 不是神，也不只是一把锤子

我们熟悉的工具都很听话。锤子不会自己决定往哪里敲，Excel 也不会算到一半，告诉你「已经完成」，实际却漏了四行数据。

AI 不一样。你给它一个目标，它会自己拆任务、选方案、修改文件、运行命令，有时还会主动补上你没交代的部分。这也是它有价值的地方：如果每一步都要人手把手指挥，它就补不上工程实现的缺口。

问题也出在这里。它会选路，也就可能选错；它会补空白，也就可能自作主张；它会报告完成，也就可能在证据不足时过早下结论。

所以我后来不再把它当成一个普通工具。我更愿意把它看成一个干活很快、懂很多技术，但有时会含糊其辞，也不能为结果负责的新人。

「把 AI 当员工管」说的是这种工作关系，不是说 AI 真的成了员工。

技术方案、代码实现、测试编写、错误排查、文档整理，可以大量交给它。问题定义、业务取舍、风险边界、优先级和上线认可，必须留在人手里。

执行权可以交给 AI，定义权、裁决权和验收权不能交。

四、把 AI 从「会写」管到「能交」，我主要做四件事

如果换成熟悉的售前语言，这套流程其实一点也不陌生。

售前先做需求访谈，弄清客户真正要解决什么问题；然后写方案、划范围、列假设条件；接着做 Demo 或者 PoC，用真实场景证明方案可行；项目落地以后，还要验收、复盘，再把重复出现的做法沉淀成标准方案。

带着 AI 做工程，大体也是这条路：问题定义对应需求访谈，规格和 PRD 对应方案与范围，AI 实现对应把方案做成一个能运行的版本，测试和真实操作对应 PoC，部署与验收对应项目上线，最后再把教训变成规则和可复用资产。

严格说，PRD 和售前方案不是同一份文档。售前方案重点回答「为什么这样建、总体怎么建」，PRD 和规格还要继续回答「具体怎么表现、边界在哪里、最后怎样验收」。但两者用的是同一种能力：把客户一句模糊的话，变成一份可以执行的约定。

PoC 也不是全部验证。自动化测试先证明系统在工程上没有明显问题，PoC 再证明它放进客户的真实场景里，能不能完成那个关键任务。一个偏工程底线，一个偏业务可用，两部分合在一起，证据才完整。

所以，对售前来说，AI 编程并不是突然跨进一个完全陌生的行业。它更像是把你原来做到方案和 PoC 为止的工作，继续往实现、上线和验收方向延伸了一段。

1．先把任务写清楚

我不会从一句「帮我做个系统」开始。真正动手之前，先把几个问题落下来：给谁用，解决什么问题，这次做到哪里，明确不做什么，最后怎么验收。

这些内容不一定要写成很正式的 PRD，但一定要留下来。对一个不读代码的人来说，规格、测试和验收记录，就是我和 AI 之间的合同。

合同的意义不是写得长，而是出了分歧以后，能回到同一把尺子上。否则 AI 每次都可能按自己的理解往前走，人也只能凭感觉说「好像不是我要的」。

2．技术实现可以放权，业务复杂度不能放权

AI 有一个很常见的倾向：过度设计。

比如只是让业务人员纠正一条错误数据。现实中，这类操作并不复杂：责任人确认问题，直接改正，系统保留修改人、修改时间和前后值，通常就够了。

但 AI 很容易顺着「企业级系统应该严谨」这个方向，一口气补出申请、多人复核、审批、驳回、消息通知、权限分层等一整套流程。每个环节单独看都很合理，拼在一起也显得很完整。可真正放进业务现场，原本一分钟能处理的事情，变成要找几个人、点好几个页面才能完成。

最后的结果往往不是管理更规范，而是产品越来越重，业务人员嫌麻烦，干脆不用。

AI 熟悉大量通用的软件设计方式，却不知道这个动作在你的企业里多久发生一次、由谁负责、错了能不能恢复，也不知道现场的人愿意为它多走几步。技术上可以成立，不代表业务上值得存在。

用什么框架、数据怎么存、修改记录怎么实现，我可以听它的建议。但要不要增加复核和审批，这些环节带来的管理价值能不能抵过使用成本，必须由懂业务的人裁定。

AI 擅长把流程补完整，人要负责把根本用不上的流程删掉。

3．不让结果自己证明自己

有一次，AI 告诉我某个阶段已经完成，可以交付。我自己进环境跑了一遍测试，结果有 4 个失败，其中还藏着真实问题。

从那以后，我立了一条很简单的规矩：不准带着失败的测试宣布完成。

AI 说做完了，只能算一次汇报。真正的完成要有证据：测试结果、实际页面、接口返回、运行日志，必要时再让另一个 AI 或懂行的人独立看一遍。

我自己不具备逐行审查代码的能力，所以会把更多精力放在过程和证据上：测试到底跑没跑，服务到底重启没有，页面到底点通没有，结果到底符合不符合业务规则。

这不是说代码不需要评审。涉及权限、安全和关键生产系统时，代码审查仍然需要专业人员参加。它只说明一件事：看不懂代码，也可以审证据；但看不懂代码，不能成为免检的理由。

4．该停的时候，果断把控制权收回来

做某个行业的分类标准树时，我一开始让 AI 自动合成，测出来的准确率只有 41%。调整了几轮，没有实质改善。我最后决定停止这条路线，从头手工重建 270 个节点。

重建后先到 76%，再继续优化到 94%。

这个过程没有让我得出「AI 不行」的结论。它让我更清楚地知道，哪些工作适合交给 AI，哪些判断必须回到人手里。

合理使用 AI，也包括及时停止 AI。自动化不是目的，把事情做对才是。

事情结束以后，还要多走一步：把这次教训写成规则、检查项或者测试门禁。只解决眼前的问题，下次换一个会话还会再踩一遍；把教训留下来，系统才会越来越稳。

五、不会写代码，怎么对结果负责

很多人的恐惧，最后都落在这句话上：代码我看不懂，出了问题怎么办？

我的回答不是「没关系，交给 AI 就好」。恰恰相反，正因为看不懂代码，才更要把验收做成自己看得懂、做得到的事情。

你可以不会判断一个函数写得漂不漂亮，但你应该知道用户点下按钮以后会发生什么；可以不会读数据库代码，但要知道一条数据进去以后应该落到哪里；可以不会分析每一段日志，但要知道出现报错时把完整信息留下来；可以让 AI 写测试，但必须亲眼看到测试运行的结果。

业务规则、真实场景和验收标准，本来就是资深售前、产品经理、咨询顾问和实施人员最熟悉的东西。这些能力以前只能变成需求文档和方案，现在可以直接约束一个正在干活的 AI。

所以，不写代码的人并不是站在工程过程之外。他换了一个位置：不再亲手砌每一块砖，而是负责图纸、边界、验收和最后的签字。

六、第一次动手，别从「做一个平台」开始

第一个项目最好具备四个特点：小、清楚、可见、可退。

小，是一两周内能看到完整结果；清楚，是输入、输出和使用者明确；可见，是能通过页面、数据或者测试直接判断；可退，是做坏了可以重来，不会影响核心生产。

把一张反复处理的 Excel 变成自动化工具，给现有数据做一个查询页面，把几个 API 组合成内部助手，把手工报表改成自动生成，或者把第 2 篇里白板上的监控视图先做成一个只读原型，都是比「建设一个完整平台」更合适的起点。

开始之前，可以先写一张只有五行的委托单：

1．目标：这次具体解决什么问题？

2．非目标：哪些功能和范围明确不做？

3．权限：哪些事情 AI 可以自行决定，哪些必须先问我？

4．验收：完成时必须提交哪些测试、截图、日志或者运行结果？

5．停止条件：遇到哪些风险、失败或者不确定性时，必须暂停并汇报？

写好这五行，比寻找一条万能提示词更接近生产交付。

第一个项目的目的，也不是证明 AI 有多强。你真正需要建立的，是一次完整的「定义—实现—验收—交付」闭环。走完一次，很多恐惧自然就没了。

七、结语

AI 已经可以承担大量工程实现工作。这并不意味着软件工程变得不重要，而是人的位置开始变化了。

过去，不会写代码的人把需求交给研发，然后等待实现。现在，他可以直接带着 AI 往前走，把自己的业务理解变成一个可以运行、可以验证的东西。

但有三件事始终不会外包：问题由谁定义，边界由谁裁定，结果由谁认可。

把 AI 当员工管，不是承认 AI 是员工，而是承认自己始终是责任人。

这也正是领域型 FDE 要补上的那段能力：借助 AI 把业务问题变成生产系统，同时对最终结果负责。

下一篇往上走一层，不谈个人怎么管 AI，谈行业：当写代码的边际成本越来越低，什么开始变贵了。

我在研究这件事，也在做这件事。慢慢写，欢迎同行来聊。

引用与参考来源

1．文中过度设计、测试失败事故及相关管理规则，均出自笔者本人项目的会话记录与长期记忆文件；引用前已脱敏，不涉及客户名称、系统名称与具体业务数据。

2．41%—76%—94% 为笔者项目中某行业标准树的内部测评结果；测评集与口径为自建，仅用于说明工作方法，不与外部产品作横向比较。

3．文中关于 AI 适用范围、风险边界和责任分工的判断，来自笔者个人的生产交付实践，不代表任何公司立场。

本篇不含外部第三方统计数据。系列前四篇涉及的公开资料，见各篇文末来源清单。

—— 模界数智