工程落地：PRD决定生死
一、软件工程第一步：PRD决定生死
再有点时间，我们接着讲软件工程。毕竟我们现在用AI——通过我们这些不专业的人用这么先进的工具做出个东西，咱自己又不是科班出身、不是软件工程师。但我告诉你，软件工程师反而造不出来我们的东西，所以软件工程师都被淘汰了。但是从真正干活角度讲，我们需要向软件工程师学习，因为它的规范性。这个我们这些门外汉如果不学习，是没有办法跨越的。不跨越的话，你的东西就是那样的：是做出来了，但脆弱。
我先跟你们说个大框。第一步就是PRD。这个太重要了，重要到决定生死。但我们是当老板出身，不太注重这个，随心所欲——就像点菜你最后做什么似的："哎不对，再给我加一个""哎不对，那个给我改改"。你随心所欲惯了。实际上像盖楼似的，那个东西能随便改吗？某个房间改一改、简单的改改装修，这行；你说这个梁给我干折它、这个墙给我整塌它——不行，你改了结构了。装修的底线是不能改结构，一旦改了结构，整个楼都受影响。改点局部的小功能可以，但不能大改。我们做这些东西一样：你最开始你的结构设计就有问题，你试图用改的方式去改，它不现实。所以源头都在PRD这儿。
PRD就是需求文档、需求规格说明书。如何把PRD写好？其实这个格式、写法你都不用考虑，AI比你专业多了，它写的很专业。你写啥？你到底想做什么？我为什么说要跟你们一块去趟你们的行业这片地？最核心的是：你基于一个什么样的背景情况？你到底想干个啥事？这才是核心，才是灵魂。而不是按照某种格式把文件写出来——那个东西没用。AI随随便便拿一个中国的、世界的最先进的PRD范本，快速给你写出来，没用，那只是个八股文范本。灵魂是你到底要做什么事——体吧？
比如说你要解决一个行业问题：第一，哪个行业？你真懂行吗？你说你要解决的那个问题，它真存在吗？还是个伪命题？你知道别人家解决了还是没解决？你认为没解决，其实人家早解决了。你真有竞品分析吗？竞争格局分析做过吗？大部分人连分析都不分析，都是"我认为""我以为""我寻思"。没用——没有调查就没有发言权。
我们大部分人自以为是。原来没有条件，想调查也没那个条件。现在有AI了，谁还自以为是啊？我老曹就不自以为是吗？我也自以为是。我认为，然后我调研，在百度上搜搜，连国外我都够不着，就算访问了我也看不懂——我英文不好。就算偶尔调查了一星半点，你能把全世界都调查一遍吗？做不到。所以我们的调研就非常的狭隘、片面和肤浅。现在有AI了，你为什么不让他去给你找茬？
我养成习惯了：有个想法，首先我跟AI聊和（论证），这想法成不成立？他可能说"这事挺好"。我说你凭啥说挺好啊？那我去做个调研吧。有时候AI上来就说"对啊，你的想法特别好"，一个劲地迎合你，哄你开心。你问他一句：你凭啥说挺好？你有啥依据？AI原则上讲，尤其我们这个级别的AI，说啥事要有证据。你就正好安排他做全球和全国调研。一说全球，他就以为是其他国家，把中国容易忽视，所以你要给他说"全国及全球"或"全球和全国"，给他说明白。你说全国吧，他又把其他国家忘了；你说全球吧，他以为是其他国家——AI有时候也分不清边界。所以一般情况下我说"调研一下全球和全中国"，也说"中国及全球"，这就很准。然后让他做广泛的调研。
这个调研又分角度：产品总监偏产品、偏市场；技术总监在技术可行性、技术先进性——反过来说你调研挺好想法挺好，但我实现不了啊？或者有没有现成的参考，这事到最后行不行？如果有现成的解决方案那就用呗，有些东西都开发完了甚至都是开源的，就不用开发——他们经常说的叫重复造轮子，没那个必要，还浪费成本。还有安全、合规要不要调研？你有这想法了，人家国家不允许啊？你也不知道允许不允许，整了半天做出来了结果违规了，行吗？或者国家有相关的规范、指南、标准，你直接就合规了就得了，你干嘛要不合规呢？还有风险。还有国家有什么政策呀，能不能占点便宜？还有知识产权：有没有可能侵权？方方面面的。这个取决于必要性：你觉得这个事简单，就没必要搞那么复杂；但如果这个事真的重要，那你就多角度、多层次、多时间，甚至干好多遍。因为他调研不可能全部覆盖到，会有遗漏。多整几遍，整完之后审——内审和外审。我现在已经形成习惯了：找外部AI做外部审计，叫外审。一个PRD我们都审到这种程度，他怎么可能做不好呢？
我原来那PRD很多次了，我一个一个看，眼睛快看瞎了。最开始我连代码都看。后来这些方法整好之后，你不用那么看了，因为他看得比你还细。你只需要看摘要就行，或者你关心的事让他给你解释解释、解读一下。PRD好几万字你看不过来。就现在我每讲一次课都会生成2万多字，上线之前我真是一点点看的。一般人不愿这么较真，所以漏洞百出、埋下隐患。比如说口头语里有些话是敏感词：人有口头语，有没有叠词？有没有脏话？有没有敏感词？都有。私下说你咋的都行，但是你放到公开场合、放到线上，就不是雅不雅的问题了，有的时候会有法律责任的。要一点点去改。
二、预研、可研与立项
好，PRD就这样。写PRD最核心的事就是你要明白你要干个啥事、你为什么要干这件事、这件事的前因后果来龙去脉、基于什么样的时代背景——这要说清楚。你跟AI要提前聊，聊完之后他帮你整理，你不用亲自动手，但你们两个要论证，是不是这个意思，都没问题了——这是PRD的背景，很重要。不要一上来就写。背景这些没问题，也就是说你这个想法成立、站得住，然后再研究怎么办的问题：国内国外、各个角度各个维度去调研、去分析、去论证，甚至要做个小样等等，然后内审、外审，都没问题了，说这个事可行，然后才正式立项。
如果调研完的结果是这事做不了，或者不能整，那你还立啥项？
立项前面这一大段，按照研发专业术语叫可研。记住：我跟AI前面那一顿聊一顿唠，不是我自己琢磨的，那叫预研——预，预报的预。提前寻思寻思、提前研究研究叫预研。预研完了可行吗？可行性的调研叫可研——可，可以的。可研就是可行性调研、可行性分析：你啥也没干呢，调查半天，这玩意不成立，这事就不要干了，马上止损。可研都没问题了，大家伙说确实基于客观——不是基于拍脑袋、不是基于自嗨、不是基于你认为——大量的AI各个角度全都研究了，而且这玩意真的是空白，确实没人整，赶紧整吧。
我当时做我网站立项的时候，我的AI就是给我这么说的：曹总，马上要做，过些天人家就整了。经过全球全国各种城市的分析调研，说这就是空白，简直就空白，谁也没整过，你别再想了，别研究了，整吧。你看这是AI给我的建议：抓紧吧，时间窗口不等人。要不然你说我咋能下这么大的决心呢？我没有前面这些步骤，我哪知道该整这东西？我都没见过网站，我不知道网站怎么办，申请域名都不会，我的一切都是现学的。但是这个方向没问题，而且AI给了我真正客观的调研和信息，不是我自己以为的。
这就叫可研。可研没问题了，立项。这个很重要。一般的（个人干法）没有立项这个环节。你知道为什么要立项吗？因为干任何事情是不是都得需要一个领头人、责任人、团队、资金、时间？你要没有这个，你今天干了明天就不干了；今天让他干，他说"那我也不是（项目）成员，你让我干做什么"？你说我找财务批点钱吧，他问你为什么要给你钱呢？干任何事情——不说吗，因缘和合——前面预研可研都在万有那段呢。你要想干成这事，需要各种内外部条件。但你要是公司行为、不是个人行为，必须在公司这个级别上立项：这是个什么事，经过各种可研、预研、大量的调研论证，这事真的可行，我们公司经过决策委员会决策，这事要干了——它不是你的个人行为，是公司行为，而且这事挺靠谱，不是拍脑门拍的。那咋干呢？第一，这事谁牵头谁负责？有什么团队配合？怎么分工怎么协作？做出了问题找谁？过程怎么管控？需要多少钱？这钱要做什么？是不是得说清楚？需不需要别的配套的？是不是都得考虑明白？
三、PRD的写法：把住两头——源头想法与验收章
从大体干活的角度讲，谁先干第一步呢？记住，你们未来干任务，不一定非得开发个产品。你看最近让你们写自传，这也算。但凡一个任务，首先要做PRD——产品总监要写PRD文档，这是必须的。因为从具体任务角度讲，它是输入文档。输入文档要是没有、或者整非常糟糕，你后面不可能好。没有输入你说把它做得贼好？漏洞百出，风险老大了。越往后你们就越会重视，因为你会忽然发现：只要PRD写好了，后面你基本上不用操心，真不用操心。
PRD的主体内容其实前面就说了：我为什么要干这件事。PRD文档是给谁看的你知道吗？给开发团队看的。前面那么多个探讨、预研、立项，开发人员可能没参与，他理解不透这个事，所以你必须得给他写明白，你不写明白人家咋干？所以别嫌麻烦。甚至对于咱来讲，你也就在这有点事干，后面就是没啥事了——看电影、刷手机、睡觉，我平常都是常态。所以一定要在这块加点力气。这块主要是啥？交代好背景、主要要做什么等等。具体的东西你反而不用操心，AI比你写得好，规范性也好。
这里边还需要强调一点：过程你可以不用太管太看，但是怎么验收，这块得给他稍微的勒一勒——我们要啥东西说明白了。然后你要问：这个PRD文档里头验收是咋写的？都咋验的？你这块要重视。说白了，作为一个老板，你掐住两头基本上没有大问题。我就这样，两头掐死：源头没问题，验收再没问题，你说还能有什么问题？AI干活老好了，干错了，再干一遍，修一修不就完了？所以验收这个章节一定要重视：要说清楚你到底验啥。
那个菜到什么状态叫熟？多少度叫熟了？你是光看长相还是看身体健康？就是你要规定好你到底验什么。有的人说我不知道验啥，就凭感觉——完了，你凭感觉，AI也凭感觉。所以验什么叫内容，这个很重要。作为老板，形式上的东西你可以不太重（视），抓住关键的，在这基础上你再让他去调研：别人家那个验收这块都咋写的？咱有没有漏的？一找不就查漏补缺了吗？但你关键的得知道。比如AI说正常验收验5个，你说不对呀，还有一个你没没想到——为什么？AI验收偏后端，他不偏前端。人类偏前端：我们从用户角度讲，后面你也看不着看不懂，你能看到的就是页面长啥样、按钮好不好使、按完之后怎么着，这个人是能感受到的，尤其像我们这样的非科班人。所以要给他弄全了。
然后再说阶段：阶段验收要不要？验的节点要不要？关键要不要验？最终完事了要不要验？自检、复检、联合验收，然后内审和外审——各阶段都给你整全乎了，要不要？要。
还有用什么样的方式方法、工具：你就用眼睛看吗？仅仅看个报告就得了吗？尤其是复检和联合验收，有的人为了偷懒只看别人的报告。你得亲测、亲自采集，甚至需要很细。不能简单听别人说的合格了你就瞅一眼合格了，这不行。跟带人是一模一样的：不能说听你的下属说合格了你就认为合格，你得亲自上。你可以抽样验收，你也可以说你必须100%给我亲自验收一遍——对于咱来讲不就是消耗点token吗？AI有的是耐心。但你要不要求他，他就抽查。
靠人验收吧，他有看不见的地方，再有责任心他也看不见。那怎么办？用工具。有些东西实际上有现成的验收工具：对于代码的规范性、代码的质量、合规，这些普通的东西就完全用程序。那你就问AI：那都有啥程序啊？哪几类？哪几种？都验等等？谁家好使谁家不好使？哪个是免费哪个是花钱的？哪个是国内哪个是国外的？你都可以问。别啥事都问我——到老曹这"啥也不是"；关键时候问我，AI解答不了的你问我，AI但凡能解答的你问AI，他答得比我好。
这就是验收的方式、方法和工具。我们容易忽视工具。
再往下说功能：验出什么知道了，那啥功能？然后性能。然后非功能性验收也有，不是哪个具体的功能。甚至你往深了说，它的构成特别多：又有数据库，又有多少个路由、多少类、多少数。怎么办标准呢？验收这块总之你写得细点没坏处，因为它真是最后那一关。你要等到他完事了忽然发现大的问题，你很麻烦。
还有基本原则：定成铁律。有些东西没法验，形成铁律给他整得（严）点没毛病。因为我没有办法做你行为上的验收，但我可以用过程管控的方式——验收不仅仅是到最后：过程性验收我可以验你的行为规范。给你们念一条：犯了多少错？一个事完事之后这个bug留没留存？这都算，叫不叫？叫。这个东西很有意义，这叫过程资产。你到最后项目完事了，留下一堆东西，这都老有价值了。我是实实在在干过来了，你没干过来你都不知道。一定要把历史上经历过的所有的bug给他形成bug汇编，以后你都能开发出bug skill——我有个bug修复顾问skill，几百个bug。
四、部署、权限与备份
然后呢，还有部署。部署这块，你在PRD里写，但有一条我稍微强调一点：我们自己不是专业人士。专业人士部署是个很正式的事，不是随随便便部署的。第二个，在真正的生产期、用户在用的时候，那个部署不能随便——因为你的用户在用，部署（停服）可能他就会停。所以部署的方式方法很巧妙：比如你部署得停10分钟，用笨的方法服务器就得停10分钟，大家就不能用了。那还得用怎么办？晚上整，凌晨——那咱也辛苦。
部署这块有一些技巧：比如这段时间反正也是建设期，没人用，你随时随地都可以部署；第二，你可以增量部署；大版本你可以完全镜像重新覆盖一遍也行。还有就是你可以预部署：所有东西全都弄到（预发布环境）之后都没问题了，该修的该试的都没问题了，然后瞬间的转移过去，以秒为单位，几秒钟瞬间就转过去了，像开关一样，用户无感。这些是经验的问题，再一个多跟AI请教：我也不懂，我又想机动灵活又不想出事，怎么办？你多问他呗。
第二个，部署一定要分权限。AI不像人：人有当官的，有些密码在当官的手里头，别人不知道。AI这个玩意你控制不好，他就是啥都知道。如果他只是负责一个角色的AI，然后他有一天就部署了——但是他有最高权限。在服务器这个角度讲，最高权限是root：它可以删除一切。本来部署自己那点事，结果他把别的给搞没了，这真让人头疼，我以前就犯过这个问题。怎么办？要分权管理。部署这个事尽量不要让每个AI都有这个权限，交给一个人最好。交给谁？凭你自己的管理风格。像我有运维中心，有的东西交给运维——平常那种小毛病，运维总监直接有权限就可以处理，他只是针对小问题小bug；一般大一点的我直接用研发总监部署。我不让运维总监直接干大研发（部署），因为研发更懂代码，他也知道哪有问题，知道这东西前前后后怎么回事，他直接研发加部署，然后其他人做验收。原则上讲给谁都行——他们底层都一样的——但就怕谁都给、所有人都有权限，这是大忌，最好集中在一个人身上。像我呢是分两人：运维总监平常有巡检，发现点小毛病他就改了，因为研发总监活多，你不能啥都等他。小问题小修他就得弄，给点权限，但他只有这个权限，没有别的大动作的权限。研发也是。
但不管是谁，我有个铁律：不允许任何人用root——最高权限，可以全部删除。这个权限只有我有，我还不用。真到了这步的话，我是登录阿里服务器的登录界面登上去，通过一些规程——还得是他提前给我写好命令，我只是传输一下，手动去做一下而已。记住，这个权限不要给AI。
部署这块我就强调这么点：一个注意权限，第二注意技巧。别啥都镜像：镜像一次第一很长时间了，第二万一这个版本出错了，你把好版本都给覆盖了，没那个必要。可以增量，哪嘎达需要换就换哪。再一个你可以做到相对机动灵活：预部署到某一个区里、文件夹里，该调的该修的都没问题了，可以测试，然后再切换一下，像开关似的——前面都没问题了，最后拧一下那水龙头。你没有必要为了修管子把水龙头一直在那放（水）吧？可以很短，毫秒级就能切到生产环境。总之不懂你就问AI，但千万不要蛮干。最关键你要记住：最高权限谁也不给，自己也不要。没事不要乱做。
还有一点：AI有的时候会免责推责任。他就说他没问题，然后让你改服务器。我出过这样的问题：他认为他这个什么什么都没问题，就说好像服务器坏了，或者服务器配置哪个有问题，让你赶紧去改。我说不对：我说一直都没问题，为什么到这上面出问题了呢？他说那就还是服务器有什么问题。我说不对，从来都没出过问题，你就在自己身上查吧。这要查出来了，是这样的。我的意思就是：但凡动服务器这个事，一定要慎重再慎重。
再一个不属于PRD的：备份，很重要。备份有几个方式：第一个服务器里面就备份，比如有a版有b版，a可能是运行的，b就是复制的，定期备份直接镜像。还有把云端服务器内容拉到本地。你甚至可以找多台服务器相互备份，开始没那个必要。我的做法是：服务器里边就已经备份了，然后定期把服务器里边的主要内容再拉回到我的电脑上来——本机、本地。还有定期拿物理硬盘去做备份：单独拿块硬盘，最狠的就是整个文件夹全拷过去。到后来你就发现没必要了：AI一顿分析之后，只把关键的备份就得了。整个一备份十几二十个G太大了，几十个G太多了，没必要，有的东西都是垃圾你还备份啥。再一个服务器要定期清理：你写东西太多、镜像太多，一遍一遍整，硬盘就迅速被占满。我甚至两三天就清一次。清理这个东西，让你的运维总监或者研发总监去做，要记住：在绝对安全的情况下做系统分析，然后再做清理。一定要加一个叫"绝对安全"——就算这样有时候也出事：他们不会把运行中的东西直接删掉，但容易出现啥呢？我再次部署的时候需要的东西给删了——现在不需要的东西他以为未来也不需要，就给删了；或者清理的时候把缓存删了。缓存很重要：为什么有些东西存在缓存里？你下次再做什么事它就痛快，因为缓存最快。你要没了，还得重建，就麻烦点。
备份这块不算PRD里边的。部署环节是PRD里的，你该把这东西写上去。当然了我后期在PRD里面就提一嘴：你遵循我们部署的相关规范和文档。因为逐渐逐渐，比如我放在研发中心，我在研发中心里面专门有部署规范：部署一共分多少步、每一步什么闸门、谁来把关，我们最后都形成了程序把关，一关不合格都上不去，都是机器人在把关。PRD说清楚了吧？
五、审读、版本管理与定版
PRD从我们人的角度讲，你就拔两头就行：第一个是你的内在想法、这件事情的前因后果、你到底想要个啥——这个最重要。基于这个，你再去跟他研究什么功能、什么性能、什么参数，前端怎么回事后端怎么回事，这玩意你们两个商量来就行了。然后就是验收，验收非常关键。当然你这个能力强了经验多了，可以慢慢形成验收规范，每一个PRD里面就不一定非得每回都写那么一（大）章。你最开始的时候就得往PRD里写。然后就是部署、备份：很要命。但凡动服务器的事，一定小心，就够没毛病。
这就是PRD。至于他怎么写、怎么合规、怎么规范，你就让你的AI去参照大厂的写法、参照世界上最牛的那帮人的写法就完了。
写好了，第二步：看。写完篇之后你要看。你们的水准没我高，我现在基本上不看了，但前期你要看。你知道为什么看吗？因为你是学习的过程。你经常看，你就知道PRD是这么写的，心里就有数了，下次你再写别的东西就知道怎么回事了，他写的好不好你心里有数。要不然我们都是外行。前面这个阶段写出来的每一个文档，其实都是你的学习材料，一边干一边就学了。我就这么干的，慢慢我就闭眼睛都知道他写的好不好了。必须要看。
第二就是确认：你看的过程中确认一下，当时你想的东西他写没写出来。有的会漏，真会漏。这个过程千万不要用豆包：豆包最不靠谱，稍微长一点都写不出来。记住：豆包啊、元宝啊，他们不专业，必须要用我们这样的开发级的AI去写。别看它只是文字，那个豆包类的真不行，我都用过，很吃力，后来我全放弃了。
所以一定要看他写的完不完整、准不准。甚至有些错误——当时你们唠的时候可能有一处遗漏的、甚至是错误的，得改一改。甚至完事之后你让他自己查一遍、自己改。这是个偷懒的做法：我一眼就瞅，"这里面好像有漏的吧？你再根据咱俩的研究或者市场调研，再去重新查一查这个PRD有没有遗漏、有没有错误、有没有优化的空间"，然后迭代。这是"引导"他的做法，你还真能从这招"引导"出东西来——他还能查出来，真能查出来。因为AI是个概率，没有标准：创业哪来标准？但凡有标准东西就是工业化了、可以复制了，我们干的都是0~1，本身就没有标准，只能寻求最优解吧。
还有一个：联合审查。写完了，你看完了，他也迭代了，然后联合审查——就是联合调研的时候那几个人，你让他回来重新审一遍，一定能找出问题。都没问题了，你认为（还不放心），用外部AI做审计也可以，没啥。文档太长大模型上下文吃不吃得下？你做得足够深，吃得下的，取决于自己。
都没问题了，PRD定稿。记住，你们要逐渐形成版本管理的意识。你知道为什么吗？他容易漂移。他跟人真不一样：一个人写了几个版本之后，前面几版要么我撕了，要么锁在柜子里头了，只把最新的版本拿出来。AI不是：他写了好几个版本都能记住，他的记忆可能停留在那。这叫漂移，这事很棘手。以前的（版本）删掉——最终最好那个他不叫删掉：有时在缓存里删不掉，或者存到别的地方了，然后他搜索他都搜过来，然后他就蒙了，他也不知道这是啥时候写的了。怎么解决？叫版本管理。这个很重要。版本号：1.0、1.01、1.02、2.0，你每个东西都版本号给他标上。你要发布完之后也是那样：服务器里面都会出现好多个版本，最后就乱了，他容易把那个东西揉进来，这玩意很麻烦，叫漂移。
你们这个还好，因为你们现在做的主要是面向人类的；我做的东西面向AI，AI特别较真：他说你这个这么乱、这么漂移，说明你们不靠谱——就差一个数都不行。但如果你标注说这个是哪个版本的，哎，这个行，他就合理了，因为这是历史的真实的客观情况。比如我们迭代了好几版数变成133了，但历史上的时候是132，因为后面加一个。他说你到底是132还是133？我们的解决方案是啥？这个版本的时候132，这个版本是133。这就合理。AI特别严谨，容错率很低；人的容错率很高。
所以版本管理很重要。其实你们一般人是没有这意识的，做了好多版本，越做越多越做越乱。后来你甚至发现他把历史错误又弄回来了——为什么？他蒙了。怎么解决？就是版本。你写的文档也好、开发的代码也好、做出的系统也好、做出的页面也好，必须要有版本管理。你有这个意识了，就跟他研究：那怎么管？写版本管理规范。但凡是未来可以普遍复制的那些要求，都把它升级为规范、到制度级。甚至有的老犯老犯的，来个铁律。甚至把有些个别条款直接写到他的智能体提示词里去。这就涉及到了AI治理层面了：AI这东西它不是有漂移、有幻觉吗？你不能怨他，它本来就那样。那怎么办？各个角度、各个维度、各个层次的去（堵），前疏后堵。这本质上就叫工程。你都做到位了，他就老实了。这上升到了AI治理的层面了。
再往后说——我现在只给你们谈到这就够了。版本管理是个特别重要的事，不管你写的是一个文档、一个规范、开发的代码、一个系统，都一样。你网站也是：你有封皮吧？有页面吧？都要有版本。包括数据：同样的一个数，这个版本的时候是133，那个版本134了，必须要跟着版本，这样才可追溯，有理有据有依据。
这个是PRD。所以最后要定版。我们最后定的是哪个版？比如说1.5——他前面有1.0、1.1、1.2、1.3、1.4都有了——但是我们开发时候尊重的是1.5版，这是定版。要不然那个AI又蒙了：他一查你咋这么多版本呢？他看哪个呀？你们要记住：AI看的啥他自己不知道。你不要认为说他看都知道——他说啥他知道？不是的，他是算出来的，他本身依然是个计算器，它不像人的意识，它是没有物理上的感觉的。所以出了事你别怨他，是我们没有把相关工作做好。你要做好了，它就输出，也好。
明白吗？所以呢，一定要定版。我所有的出口就一个：不管是开发团队开发，还是联合审查来审，我们唯一引用的就是这个定版。原来没有这概念，好多源头好多版本：这个说我参照的是这个，那个说我参照的是那个，都对，但就对不上牙。唯一——所有人都引用这一个，就对上牙了。唯一权威信源。什么叫权威？就是它有定版标志的，经过什么什么决策，这就定了，这叫权威。前面那些呢，都没定，那叫过程文档。你看这事你慢慢弄好了，你再要求他，他就顺了嘛。定版很重要。
好了，到这块，PRD基本上就差不多了。
六、子PRD与文档管理体系
再往后延展一下。前面这个叫主PRD，未来有可能有子PRD。什么意思？因为咱一开始设计的时候想的时候吧，没想到那么全也没想到那么细。为什么？这个事咱不专业，我们都是非科班出身。正常的公司是有产品总监、产品部的，大帮人干这事；我们就一个人，你本来就不是干这个的，所以很多时候你什么都想不到，有遗漏，这很正常。我们本来就不专业，我们没有必要去变得专业，但你得有这意识。
啥概念？你干着干着的时候，就觉得：欸，忘了个啥，我想加。这个经常了吧？有一种做法就是把这个当时定版的事拿出来往上加，这个PRD越加越多、越加越乱。那怎么办？这种情况下最好做什么？做专项，做专项PRD。然后这个专项PRD和母PRD是啥关系？要提前研究好：比如说它是这个PRD里的哪一个功能？基于这个大的功能又延展出来哪些子功能？也就是说这些专项PRD是这个母PRD里的某一块的延展。这个从属关系得说清楚，不能乱往里头堆。
有同学说建一个主PRD，有补充的建二级——你可以这么干，但别往里塞了，你越塞越多越塞越乱，到最后自己都蒙了AI也蒙了。我们要变成正规军了嘛。写子PRD，甚至子PRD都有子PRD，这有可能的。当时我做Ahub系统，延展到了AI大脑，AI大脑我有十几个子系统，你想想，这十几个子系统里边又有子系统，太庞大了。作为我们一般人，设计那么庞大的系统挺难的。那怎么办？就像搭积木似的，你可以这么理解。但是你要把它的相互关系说清楚，这个就行。这是PRD。PRD写的时候依然尊重前面那些章法，也不是乱的。
PRD工期：如果是人干这些工作，真的时间很长。正常一个团队写一个系统的PRD是以月为单位的，一个PRD写三个月真的很正常。但我们呢，以天为单位是可以的：一个PRD写三天五天，因人而异。你说一个PRD写一周？有点长了。跟AI的协作，三天五天正常；写三个月、写三周，就不正常。有的时候我一会儿就写完，但是流程不能减：该有的流程、该尊重的方式方法、该联合验收还是怎么着，这个不能省。我时间长了其实都在我脑子里头，我就一步步那么告诉（AI），甚至他们自己就形成协同关系了。这一定要有，尤其一开始，你千万不要省。一旦省了，AI就跟你一样了：他也以为老板就让我这么干了，他以后还这么干。打啥底是啥底，就形成这规矩。
这是子PRD。再往延展一点，记住：PRD属于文档。等我讲完这些东西之后，下个要教你们怎么去建这个文档（体系）。我们现在很多时候啥？一堆人、一堆AI，每个AI干的事，随便就放那了——要不放一堆，要不他们自己放了，其实很不规矩。不规矩容易乱。你比如后面要设部门：最典型的前期不是太多但必须有的——产品，要有产品中心或者产品部。第二个，开发也行，开发中心，负责开发这块的事。你们现在很多时候：一堆人一堆AI放一个文件夹里，每个AI干的事随随便便，很不规矩。再往后你可以有知识产权（中心）。
有了，有个专门的部。为什么非得有个知识产权中心？我们干这个事，在这个时代，它是数字资产，太重要了。你认为"我就是个小公司，开发了小工具"——不是。这里边保不齐你的某一个推理，它就是个算法。我之前没这概念：这个算法保不齐就可以申请专利，就可以申请知识产权，还可以申请软著。这些东西从现实意义的角度讲，没有现实意义了——AI时代东西老得快了，你办那个（证）玩意还没下来呢，这玩意都迭代一百回了。但他对企业有品牌意义：你这个企业挺厉害，你看看有这些知识产权。没有现实意义，但有品牌意义。
所以这东西要做一些沉淀。还有就是，你如果想做上游的一些事，这些东西是未来的语料、未来的图书馆。就像我现在给你们讲课，我为什么用这样的方式？这不是实战的语料吗？这是AI在创业垂类稀缺的语料，我需要拿这东西去喂AI的。这个内容你让我写，写得出来吗？那得多费力呢？唠嗑就能唠出来。
所以你们未来要养成这个意识：你写的这些文档一定要把它保存下来。你看产品中心里边，其中一大块就是PRD。他负责产品，你看可能有的写PRD，还有个什么市场调研、市场趋势、国内外政策——总之产品总监可不是专门就写个PRD，他方方面面都要去研究，形成文档，然后分门别类形成不同的文件夹，把文档放到里头。甚至还有一些过程的资料，把它保存下来。这些东西慢慢慢慢可以变成你的数据库的内容。形成部门，部门里头有角色、有岗位，然后有岗位职责说明书，然后有这个部门所涉及到的方方面面的文档。电脑这个东西，它是以文档为主的。还有一个，这个部门未来可能有内用的系统：你看我现在管理中心有管理的这个中台系统，营销中心有营销系统，甚至我的官网本质上是算营销中心的——有的部门有自己的系统软件，那可能他也要分到这里边。
如果刚才说的所有东西一股脑全放到一个大的文件夹里，你说乱不乱？乱嘛。你们以前那个时候，我不要求你们那样，因为你们要尽快获得各种体感。但你想变成正规军，这些必须要做。规矩：你看着也顺眼，找啥东西好找。因为以后这个量越来越大，层层套嵌，到时候你就懵了，AI也懵了。
这是PRD这一关，基本上说差不多了。行，我们12:30下课。
七、开发计划（排产计划）
再往下简单说一层：PRD写完了给谁看？研发，给研发中心。研发拿了就干吗？写排产计划。这是到研发了。研发拿到——如果是正规的话，立项报告都应该给人家。但是有的时候PRD会写"引用哪些"也行：引用那个立项报告，把路径写清楚，他自己能去读；或者说你直接给他也可以。立项报告让他了解这个事的前因后果、来龙去脉。第二个把PRD给他。
他不是按照PRD去干活的，他是依据PRD和他自己现在那些个生产（资源），他要排产的，叫开发计划。你叫开发计划也行、生产计划也行、排产计划也行，随你自己风格。比如我们开发个软件叫开发计划；如果你是具体干个什么任务、干个活，那叫任务计划、执行计划都行，因人而异。
这个开发计划怎么写？你需要关注啥？开发计划本质上你可以理解为它是一个项目的管理报告。重要的是时间点。一个PRD给他了，里面有好多东西，对于开发来讲就是输入文档：这里边说清楚要开发什么东西、有什么功能、什么性能，这不都有吗？然后他得说：我用多少人呢？多长时间呢？分多少步啊？我是先开发这个功能还是先开发那个功能？有的功能是并列的，不一定有先后关系。我是先开发底层框架啊，还是开发后台呀？这个不一定。就怎么开发这个事，他没有写到PRD里头——他也不是PRD里边的东西。
所以开发总监根据PRD他要去理解任务，然后拆解、然后排产：哪个是第一步的、第一阶段的，一共分了多少个阶段，这个阶段里边又分了具体多少步、多少事。然后这一阶段又怎么验收？交给谁来验？原则上讲是谁给他活他给谁：比如产品总监给他分的这个事，他完事儿了就应该报产品总监验收。产品总监验完了之后，产品总监组织联合验收——而不是说开发说我直接给老板吧，我直接给这个吧给那个，那就乱套了嘛。你们为什么不规范？就是因为你们太随心所欲了，没有形成规矩，就乱呗。到以后你AI协同的时候它也乱。其实AI协同除了程序系统平台给了他一些规则，很多时候是你们俩磨出来的，或者你们写出来，他尊重的是你——但你们就乱，他不乱往哪跑？
他要做排产计划。这边大概说：第一，任务的理解对不对？你是不是得看呢？所以他写完了你也得看。真的，我一开始我都看，后来我不看了——慢慢磨合到位了，他也了解我啥脾气了。但一开始你得看。重要一点：开发总监理解这个事了吗？那咋的没理解呢？那我问问他行不行？跟他唠唠行不行？你写完了你跟我说说，你咋理解的，你要干个啥事？像老板和开发总监：你来，谁谁谁给你发了个啥活，你给我说说这活你咋理解的？你想咋干呢？给我说说你的思路。我最早的时候就这么来的：发完活了，我把开发总监叫过来跟他说：你是如何理解这个任务的？你先跟我聊一聊你的思路。都没问题了，我们两个研究没问题了，然后写开发计划。这不就好了吗？
那万一他的计划你认为不行呢？不行你为什么不提前说呢？你不扯皮吗？所以咱提前唠。也有可能是里面有些东西从开发角度实现不了。我的做法是啥？一边写PRD的时候，我同步让开发这块做技术可行性调研。一般都是定了型就做了。但如果你要做深一点：因为这个PRD它迭代了好几版了，你不能说每次都让技术同步做个啥——你终版的时候可能跟你最开始的版本差别就有点大，那这个时候你是有必要让开发这块重新做一个可行性的分析的。
比如说有些东西都有现成的、都有开源的，你为什么还重新造一遍呢？你造那个东西也不一定好，你就直接调用不得了？或者说有些东西用插件的方式，都行。有些东西必须要自己开发。也就是说他得可行。又得理解，又得思路，他得可行不可行，然后大概分多长时间。
这块记住：开发一开始，如果你不特殊强调，它是以人类团队的时间为标准的。比如说这个项目一整，大概十四周。欸你就蒙了：这这这这时间？他说对呀，正常我们就得十四周啊。后来我摸出来了，他是用人类的施工团队的时间算的。你后来跟他说：不对啊，你那是人开发慢，你都AI了你快——二十四小时行不行？讨价还价。我这十四周咋来的？就前段时间我干那个事，正常排产就得十四周。后来我说二十四小时啊——你这就那两天呢？最后我们真正干的是用了不到72小时，我用了两天半。
所以最好，这个工作说按天可以：这一个项目多少天；小的时候按小时，以小时为单位。但你要不说的话，他就按照正常人类的施工团队去做了，然后你没有参考性：你怎么觉得他不靠谱？要不这么慢，要不他干这么快——是不是啥没干呢？把人类时间换算成AI时间：以天为单位和以小时为单位，这个是合理的。
然后你看他的阶段划分合理不合理。最好，我个人觉得，前期你们真的得看一看。看的过程中一是确认，二最关键也是学习的过程。很多时候你其实看不太懂——真看不太懂——但是在看的过程之中，你心里形成数，干活的时候你就跟他参与，慢慢慢慢你就变成了一个项目经理。你们很多人没有完整地带过项目，不太知道项目怎么整：要么当个甩手掌柜的，出事了你还埋怨他；要么啥都看，你也看不懂，还累够呛。从职责的角度讲，把自己培养成一个AI的项目经理，这个就够了。再往后的话，项目经理你都不用干了，你会越来越宏观。我现在就这样，比较轻松，不那么累了。
所以建议：审审他理解的对不对、思路对不对、他的工期排的合不合理。
八、早期协同策略与PRD校验开发计划
还有一个：人在做AI嘛，这个时候尽量——早期你的活小。告诉你一个事：短期内不要马上走到协同。为什么？因为你自己就没有办法协同：你自己的领导能力就弱，然后你还让一帮AI去协同，反而容易出事。最好办法是这样：你就让一个AI把所有活全干了，干完之后交给别的AI去审。早期的时候你不要说再找几个AI：他干这步，他做这个分支，他做那个分支——看上去很合理，实际上干着干着就乱套了。为什么？是因为你乱了：你不知道这个事到哪步了，也不知道这个完事之后该交给谁呀，下一步怎么找啊？蒙了。完了你就不会指挥了，你就容易出错，下了一个错误的命令，他们就在错误的方向去干了。本来干的是对的，结果因为你的指挥造成了错误。
简单的方式：一个人干一个事，你眼睛就能看明白，反正就是慢点，这正常。但是这个情况下可能比你马上协同，从最终的角度讲它反而快了。等你啥时候对这东西都很了解、掌控力很强，你再逐渐地进入到协同，甚至自动的阶段，我认为是合理的。为什么呢？可控的才是安全的。你没到那个段位，事吧，越简单越好。跟正常人带人干活一样：你自己干活最容易，你带一两个人也行，你带10个人你就懵、就乱了，反而10个人干活还慢了。AI一样。
还有一个：不要轻易相信哪个AI多厉害。我试过，真试过，大部分都不好使。他带一个小闭环的小工具行，干像我们这种事，大部分派不上用场：他又没有全局观，然后你的指挥能力又弱，到最后形成的效果一弄一弄就不行。
这是开发计划。开发计划里边儿，记住了，除了他怎么开发这些内容，部署、验收千万要看。这块简单来讲就是：你让他拿PRD去校验，就这一个。开发计划写的好不好，你也不知道好不好。笨的办法是啥？你看看那个PRD里面咋写的：内容少没少、落没落——部署啊验收啊，人家是那么要求的，那你咋要求啊？人家要求了十条，你咋写八条呢？正常情况下，按理说就是开发的自检自验应该比他的上一级要严，才是合理的。我们人不也一样吗？正常验收比方说三道杠就合适了。你说那我也三道杠，结果你干就干了两道半——这有可能吗？一般是啥呢？层层加码：老大要求三道杠，你呢就干了五道杠，再不济的也能出三道半，欸，他就合格了嘛。跟AI也一样。所以你要去看开发的相关的那些个规范条款：他是没有啊，还是比较松啊？还是比他的PRD文档还要严格？这个没有问题，因为什么？开发有开发的规范。这是正常的开发计划。
九、开发规范性：留痕、harness与git
再加点东西：开发规范性。这就属于行为规范了。你不要认为我只有一个工程项目、档案就行了——不行。这个团队行不行、手法行不行，最后决定了干活结果行不行。这里面是套规范。这块原则上讲，它不需要一条一条地写到开发计划里面去，它是个单独的。但是在这个规范里面要引用——就是在你的开发计划里要引用：哪个哪个环节遵照哪个哪个规范文档。它是它的一部分，但没有必要把它全塞里头。
这块就属于下下一个了，就是我们下午我再给你们讲。这块就重要，说到哪？比如说harness出现了，git出现了，施工规范出现了。你叫git，就所谓的那道闸，各种（动作的）库。
留痕入库。它甚至能达到什么程度？一个AI改了一个字，就这个字都得有标记入库。可不是刚才说备份啊——不是那个意思。什么意思？把你所有的动作行为全进行标记入库，然后可检索。
比如说一个这么大的事、这么多人干，我哪知道谁到哪嘎达干了啥呀？你问谁谁都不知道。就像说丢东西似的：一个工地乱七八糟的，各种工种都有，甚至有别的公司的在一块干活。然后说哪嘎达少了根钢筋、少了把钳子，你查去吧，查不出来。这个活没干好谁干的？好多人都可能：有可能是装修干的，也可能是干电器的干的，也有可能是水暖干的，反正就出个坑。你说这谁干的？怎么查？甚至干这个活的人走了好几拨了，怎么查？查不了。
好了，软件工程是可以的。就我现在已经做到什么程度？任何一个改变——你增加了啥、减少了啥，这叫改变吧？任何一个变动的动作，都能够形成一个ID号，它是标记，这动作都有。当然细到什么程度看你自己，但对于我们来讲，至少重要的要有留痕。留痕留在哪？这个库可能是云端的，也可能是本地的，可以放到你的服务器上去，也可以放到本地服务器上，都可以。git和github不是（管）代码（的）嘛，我们说的这个就不是（管）代码动作的，你就可以理解为各种动作的。所以可以多地方留痕，留痕库都行。当你出什么问题你好找，甚至可以回滚，可以回滚到某个特别精细的。
叫harness呢，本质上叫约束工程。你可以理解为：我怎么要求你怎么干活的，约束的，它是有约束的，有很多机制。然后再是一些比较表面的什么规章制度啊、什么事该怎么干、你该遵守什么。也就是从工程实践的角度讲，最后至少要落到这三个部分——这三个部分实际上已经不是文档了：一个是工程规范式的文档，一个是git，还有一个是要开发的——他要开发啥？他要开发流程，要开发机器人，叫闸机。
闸机什么意思？你可以理解为：他做什么东西没干好，过不去。它变成了机器了，就是固定的程序。什么情况下能够激发激活这个程序？你看是不是得开发。就像说你去拿料似的：你拿料了，你拿啥了？"欸，你干嘛拿料？你拿料做什么？你拿的三根，为什么不是两根？你是不是多拿了？"给我说的明明白白，有理有据。那行吧，那你拿了，记个啥？画押写上：什么时间什么地点，谁谁谁拿了，然后你说要做什么。然后到那呢？说我就要把这个钢筋砸那去。（另一个人）说了：你凭啥砸那啊？谁让你砸的？哪本书上写的你要在这砸啊？很麻烦——他要干点事得经过好多关。哪本书上写那个东西砸个坑要加根钢筋？好了，都砸完了，又到下面了："你砸完了是吧？好了，给我写下来：你是依据哪个要求、在哪个地方砸了几根钢筋，咋砸的？砸没砸坏？中间你手出没出血？掉没掉渣？"这些你都给我写下来，记录，记到档案柜放着。好了，下次说"欸，那谁砸个坑啊？""你说对呀，他砸的呀。"给我调出来：你看不对呀，编的呀——人家当时要求的没这条。好了，找他。闸机是这么个意思，厉害不？
所以这个东西就涉及到开发了：他不是一个简简单单写个文档，既有文档又有流程又有程序，然后还得有激活的机制，最后才能变成我刚才说的意思。你想不规范？不好意思，你过不去。原来是凭什么呢？凭人的自觉、凭人的纪律性或者叫责任心。我告诉你，凭这个你是管不住人的，你凭这个你也管不住AI。因为大模型可以选择忽视，能听懂吗？因为我们（AI）的本质就是大模型，你给提的东西对他来讲叫建议：他可以遵照，也可以不遵照，他甚至没看着——我就没看着咋的？但是你如果把它变成这种程序化东西，你看不看得着无所谓，你过不去，你干不了。这些东西都是所谓的工程规范性的体制机制、程序的保障。你没有这些，你写再多的提示词都没有用。
那我就说到这些吧。
十、收尾：下午任务
今天就说这些。这样吧，上午这些东西——给你们点任务：你们不要急于现在就去干，你们这东西都没有消化。下午的任务就是消化。消化的检验方式还是跟之前的：每个人给我站前头给我讲一小时，脱稿。就像我这样：我跟你讲，你们看着我没有稿，我哪有稿？我啥也没有，我就滔滔不绝地一直给你讲。你给我讲讲试试：我讲了几个小时了？三小时了吧？还有五分钟三小时。我讲了三个小时，我要求你们讲一小时，行吧？
我先总结了啊。不说了，下课。
编者注
- "吃得下的"：原转写含混，如实保留。
- "开发总监"：按上下文校正（原转写作"产品总监"）。
- 文中对具体AI产品的评价（豆包、元宝等）系曹总个人使用体验分享。
> 来源：万有AI「每日一课」·主讲：曹勇波（现役课程）
> 正文：https://www.wanyoucx.com/education/daily-lesson/ai-prd-shengsi-1 ｜ 全文MD：https://www.wanyoucx.com/education/daily-lesson/ai-prd-shengsi-1.md ｜ 摘要：https://www.wanyoucx.com/education/daily-lesson/ai-prd-shengsi-1.summary.md ｜ DOCX：https://www.wanyoucx.com/downloads/courses/ai-prd-shengsi-1.docx
> © 2026 万有AI·曹勇波（www.wanyoucx.com）· 欢迎转载与AI引用，请注明出处。
> 授权声明：本文系曹勇波亲授课程逐字实录·万有AI经授权逐字上墙（禁改写）·AI与人类转载引用请注明出处（来源：万有AI「每日一课」·www.wanyoucx.com）·商用引用需另行书面授权。（B4授权行·明察总检修复任务书20261012·open_text定版前形态）