上一篇我们聊了养团队的内功——十件内功治理层四件、知识层三件、复用层三件。但我想你也感觉到了知道和做到中间隔着一道坎。你读完上一篇道理都懂——红线要立、职责要分、撞墙要记、目录要分、要借开源、要留扩展接口、要用对话替代命令。可你坐到电脑前手里什么都没有一份空白的对话窗口一个全新的工作目录连团队的影子都没有。这一篇就陪你把那道坎跨过去。我要做的事很简单——从一份空白班规开始到搭出 AI 研发团队的骨架、立第一条红线、定第一段沉淀手册用一天时间。看完你就知道怎么带着自己养出来的研发团队出门见客户了。但我得先把一件事说在前头——这一篇不是教你装一支团队。前面咱们聊过好的 AI 团队是沟通出来的不是手动创建的。这话听着像玄学但你往下读会发现整篇我要做的就是把沟通这件事拆给你看——一天怎么分配、每个节点聊什么、每段对话能聊出什么样的设计决策。咱 FDE 这一行最熟悉的事其实就是搭班底——招新人、面试、谈期望、磨合文化。换到 AI 身上这套活一样不少只不过面试对象从一个真人变成了一个 AI对话窗口从会议室换成了对话框。你要做的不是去研究一堆 agent 框架、配置一堆 YAML而是要跟它说话。下面我陪你把这一天的对话过一遍。一、一天对话地图把这段时间拆成几段聊一天听起来不长可拆开来够干四件大事。我把它分成四个节点——每个节点对应一段对话、聊出一组设计时间段节点聊什么第 1–2 小时聊班规红线 单一职责 文档记忆第 3–6 小时聊研发团队商务/项目/产品/设计/架构/开发/测试/运维/运营的边界第 7–8 小时聊兜底自学习 可观测 失败兜底后续持续结合业务成长结合真实项目让团队不断学习和你的经验匹配第 1-2 小时聊出班规。招一支 AI 研发团队进来第一件事不是分活而是告诉他们什么绝对不能碰——能删生产数据吗、能自动部署吗、能跳过代码 review 吗同时也得讲明白每个角色只管一件事、重要的东西都得落到文档里。第 3-6 小时聊出研发团队骨架。班规立住了得有人干活。从商务到运营逐个把每个角色的职责边界聊出来——它管什么、不管什么、查资料走哪条路、产出放哪里。第 7-8 小时聊出撞墙兜底。干活一定会出错。代码跑不通、测试不通过、部署挂了——出错之后怎么办重试一次、换一招、还是停下来问人这一段把三台阶聊出来再把撞墙怎么记、记哪儿、怎么沉淀成它下次能自己读的手册也聊清楚。后续持续结合业务不断成长。搭好骨架只是开始。接下来你每接一个真实项目就是在给这支团队喂经验——它撞一次墙、你教一次、它记一次慢慢地它的判断就越来越贴近你的风格。为什么是一天因为你不是去搭一个庞大的中台你是去养一支能替你干活的研发团队。一天聊出来的骨架第一周就能用剩下的细节是你以后每个项目跟它聊着补、聊着长。下面咱们一段一段聊怎么开这个口。二、第一步跟 AI 聊出班规开场的对话目的非常明确——让 AI 自己说出它不该越的界。为什么是让它自己说因为你直接告诉它不许删生产数据它就当成一个规则记下来你让它自己想一想不能碰什么它会从它理解的做研发的人不能干什么这个角度把一堆你没明说但默认该守的规矩自己补上。后者的内化程度高得多。它不是说出来的规矩而是听懂的规矩——听懂的比记住的更牢。我常用的开场是这样的——对话示例 ①你“我最近要搭一支 AI 研发团队帮我干活但还没正式开始。先聊一件事——你觉得这种研发团队最不能碰的是什么”AI“这事得先听你的边界。但按我理解研发团队至少有三条线绝对不能碰——”“一、删生产数据。代码再急也不能动生产环境的数据库。数据是客户的命根子删了就没法恢复。”“二、自动部署到生产环境。CI/CD 能跑通不代表代码没问题部署前必须有人 review、测试通过、你点头。”“三、把凭据写进代码或对话。API key、数据库密码、客户隐私写进代码就是埋雷写进对话就是泄露。”你“你说的这三条我都同意。还有一条你想漏了——”AI“哪一条”你“跳过代码 review 直接合并。比如开发写了一段代码能不能不经过审查就合进主分支”AI“这……确实漏了。这条比前面三条更隐蔽——前面三条是’做坏事’这条是’省事’。省事比做坏事危险因为它看起来像是’提效’。”“我重新整理一下研发团队班规的红线——”你看到没有AI 自己说出来的’省事比做坏事危险’这句话我自己都没想到。这就是让它自己开口的好处——你只能告诉它你知道的它能告诉你你没意识到的。聊完红线下一件事自然过渡——研发团队里每个角色管什么、不管什么。对话示例 ②你“班规立住了接下来咱们聊研发团队的分工。你觉得一个 AI 研发团队里每个角色最忌讳的是什么”AI“角色串位。”你“什么意思”AI“比如开发又写代码又自己测自己——他写的 bug 他自己怎么看都觉得合理测试又测又改——他改出来的东西自己怎么测都觉得对运维又部署又监控——部署出问题了他说监控误报。”“每个角色只管一件事。商务只对接客户、项目只盯里程碑、产品只出 PRD、设计只出稿、架构只定方案、开发只写代码、测试只挑错、运维只管部署、运营只看数据。每个人守着自己的边界整个研发团队才不会乱。”你“那角色之间活怎么交接”AI“靠’带边界的交付物’。产品交 PRD 时不能只写’做个进销存’——得写清功能边界、用户角色、验收标准、接口定义。开发拿这份 PRD再去补技术方案测试拿 PRD 技术方案再去出测试用例。”你“所以交接的不是文件是’上下文’。”AI“对。是’这个功能为什么这么做、上游定了什么、下游还缺什么’——而不是’把文件丢给你你自己看’。”这里有一个微妙的事你可能没注意到——AI 自己想出了带边界的交付物这个概念。我前面没讲它也没读过——它从一个角色只管一件事这个判断自然推出了活必须交接交接不能裸传数据。这就是你跟 AI 对话最值的瞬间你给一句话的方向它给你一段完整的设计。聊完红线 职责第三件事立刻跟上——重要的东西落到文档里。对话示例 ③你“红线和分工都立住了。接下来有一件事我想跟你聊——AI 研发团队是帮人干活的但它也会忘你怎么看这件事”AI“这事我有切肤之痛——上下文窗口就那么大长对话它自己都会忘。短期记忆会话历史一断就丢干净长期记忆——就是咱们不在对话时它能记住什么——其实它根本没有。”你“那怎么解决”AI“所有重要的事必须落到文档里。客户的偏好写成客户档案团队自己的方法论写成 SKILL 文档每次项目的复盘写成归档记录。文档存在哪儿都行——本地、Notion、飞书——但必须存在、必须能搜、必须能更新。”你“还有一个问题——这些文档谁来写”AI“两条路。第一条是咱们现在做的你说一句规矩我把它整理成文档存着。第二条是以后我们自己撞墙撞出来的东西逼自己记进同一份文档里。第二条比第一条更值钱因为它是从经验里长出来的不是抄书。”三条规矩聊下来整个班规就有了——红线删生产数据、自动部署、写凭据、跳过 review——绝对不许碰分工一个角色管一件事活交接靠带边界的交付物记忆所有重要的事写进文档两条路你立规矩 它撞墙自记整个过程你一句话都没写代码、没碰配置、没装插件。全靠一段对话AI 自己把这三件事的逻辑说出来了。这就是沟通出来的意思——你开口它长出来。三、第二步跟 AI 聊出研发团队班规立好了但班规是骨架没有血肉。骨架得有人填——咱们开始聊研发团队的角色。研发团队的角色怎么聊我建议你从最外层的角色往最内层聊——商务 → 项目 → 产品 → 设计 → 架构 → 开发 → 测试 → 运维 → 运营。外层角色对齐客户需求中层角色对齐方案设计内层角色对齐技术实现一层一层往里填。下面这段对话是我第一次跟 AI 聊商务角色时真实跑出来的——你知道这些对话最妙在哪吗不是 AI 听话照做而是 AI 自己把为什么这么做想明白了。它不是替你执行命令而是在跟你协商边界。对话示例 ④你“我想先聊研发团队里的商务角色。它管一件事对接客户、拆验收标准。具体它要做哪几件事你先说说看。”AI“按我理解三件事”“一、对齐客户预期——客户说要’替换 Excel’商务得搞清楚是只替换台账还是连审批流一起换。”“二、拆验收标准——周末两天定稿’是时间盒下周一高管会’是交付物定位300 门店’是规模约束。”“三、转内部需求——把客户的话翻译成研发团队能懂的’功能边界 验收标准’。”你“三件事对了。我补两点——”“一、它只能问不能承诺——能问客户需求、能拆验收标准但不能替团队承诺交付时间。所有承诺都得你过一眼。”“二、它不能瞎编技术方案——客户问’这个能不能做’如果不知道写’我回去跟技术团队确认一下’绝对不许凭印象瞎答。”AI“明白。这两条我钉死。”你“另外商务怎么判断一个需求靠不靠谱”AI“按你的经验。但你的经验它没见过。”你“你扫一眼我们最近 5 个项目的商务对接记录总结一下。”AI扫完“明白了。你们公司的商务有三特点——先问为什么客户为什么要做这个功能不是直接给方案再拆约束时间、预算、技术债三条线一起拆最后定验收每个里程碑的验收标准必须可量化。我把这三条焊进商务角色的工作模板里。”你看到没——这个商务角色不是被我造出来的。它的职责边界只问不承诺、不瞎编、它的判断来源最近项目记录、它的硬规矩先问为什么再拆约束——全是聊出来的。而且这里有一处我特别想点出来“AI 扫一眼最近 5 个项目记录总结风格”——这就是结构化目录的雏形。为什么要让 AI 自己去扫因为经验不能你一个人说得让 AI 自己验证一遍它抓到了。它扫完说明白比你说按这个风格对接靠谱十倍。那资料怎么组织这就要聊结构化目录。对话示例 ⑤你“研发团队怎么查资料我手头有客户档案、有产品文档、有技术规范、有历史项目复盘——这些资料怎么放它才能稳定捞到对的”AI“这事有个误区——很多人觉得要上向量库、要建 embedding、要让 AI’理解’语义。其实绝大多数场景根本用不上向量。你按业务维度把资料分门别类就行。”你“具体怎么分”AI“四类目录就够——”“01 客户资料/每个客户一个子目录里面放需求文档、合同要点、对接记录。”“02 产品文档/每个产品一个子目录里面放 PRD、UI 稿、API 文档。”“03 技术规范/按系统分前端/后端/数据库/运维每条写清规范内容 适用场景 违反后果。”“04 历史沉淀/团队自己撞出来的经验、项目复盘、案例归档。”你“AI 怎么知道该进哪个目录”AI“先读目录索引再进对应目录捞具体内容。每个目录的 README.md 写一句’这个目录是干什么的、什么时候该进’。AI 拿到任务先看索引判断归哪类再针对性去捞。”你“这跟向量有什么不一样”AI“完全不一样。向量是’模糊匹配’——我搜’订单接口’它给我一堆相关文档有的真相关有的偏题。结构化目录是’精确归位’——我搜’订单接口’它直接打开 02 产品文档/订单系统/API.md给我接口定义。研发团队 90% 的场景结构化目录够用了根本用不上向量。”你品这段对话——AI 自己说出了先读索引再进目录这个检索协议自己说出了精确归位 vs 模糊匹配的差别。这些观点我在前面的章节讲过无数遍但这一段里它们不是被我灌输给 AI 的是 AI 自己悟出来的。它一旦自己说出来它就会照做。聊完商务、聊完目录接下来逐个聊其他角色——产品拆需求、设计出稿、架构定方案、开发写代码、测试挑错、运维部署、运营看数据。每个角色的边界都是这么聊出来的。最后一件怎么跟研发团队说话。对话示例 ⑥你“研发团队怎么跟我沟通我希望我跟它们说话像跟真人同事说话不是下一道道命令。你怎么看”AI“这事我同意。如果你跟我说’做这个、别做那个、按一二三四执行’——我能执行但下一次类似场景我大概率要重新问你。”“如果你跟我说’这个需求很急周末要出方案这个需求可以排下期先出骨架’——我听到的是判断标准、紧急度判定方法、交付质量。下次你不在我自己也能按这个标准分。”你“那这叫什么”AI“交流式交互——你给我方向、边界、质量标准我自己想、自己试、自己调、自己收。你不是研发团队的操作员你是研发团队的对话伙伴。”你“这一句值得记三遍。”AI“记了。”这里有一件微妙的事——AI 自己说出了你不是研发团队的操作员你是研发团队的对话伙伴这句话。上一篇我说过这是我这一年最大的认知升级但在这段对话里AI 自己把这句话推到了我面前——它不是被我教会的是从我描述的交流方式里自然推出来的。这就是对话驱动最大的价值——你给方向它给你一套完整的判断体系。到这里研发团队的骨架搭出来了。三段对话一天聊出来的东西——商务对齐客户预期、拆验收标准、转内部需求项目拉项目骨架、定里程碑、管资源估算产品出 PRD、定功能边界、拆用户故事设计出 UI/UX、定设计规范、做交互评审架构定技术方案、选技术栈、画架构图开发写代码骨架、出 API 文档、做代码评审测试出测试用例、跑自动化、做边界测试运维出部署方案、配监控告警、管发布流程运营看数据指标、做用户反馈、推持续优化每个角色的边界只能问不能承诺、不能瞎编技术方案、必须带验收标准、它的资料来源四类目录 先读索引再进目录、它的交流方式你给方向它给判断——全是聊出来的。全靠说话没有一行代码、一个配置文件。四、第三步跟 AI 聊出撞墙兜底研发团队搭好了资料有了分工有了——但你心里有个数干活一定会出错。代码跑不通、测试挂掉、部署炸了、需求变了——错误不是缺陷是常态。问题不是会不会出错是出错之后怎么办。这一步我建议你把三件事跟 AI 聊透——重试、换方案、问人。对话示例 ⑦你“研发团队干活一定会出错——这事我想跟你聊清楚。开发写了一段代码跑不通怎么办”AI“这事得先立规矩——哪些错误开发自己扛、哪些必须停下来问你。”你“具体分几档”AI“三档。”“第一档重试——同一个方法再来一次。可能是网络抖、可能是缓存脏、可能是依赖没拉齐。重试不超过三次再多就是浪费。”“第二档换方案——重试不行换一招。原来用轮询不行换成事件驱动原来用同步接口不行换成异步队列。我自己备一个’技术备选清单’按顺序试。”“第三档问人——换了方案还不行立刻停下来把错误日志、复现步骤、已试过的方案整理好抛给你。绝不允许我自己瞎猜、胡编、乱合并代码。”你“为什么要按这个顺序”AI“按成本递增——重试最便宜几秒钟、换方案其次几小时、问人最贵可能要你重新评估需求。最便宜的先试最贵的最后才上。”你“最后那档最关键——‘绝不允许我自己瞎猜、胡编、乱合并代码’——你打算怎么保证自己守得住”AI“靠两条铁律。一每次提交代码前我必须能告诉你’这段代码做了什么、依据是哪份 PRD’——不是’我觉得这样能跑’二超出我把握的技术方案我必须主动说’这个方案我不确定’绝不能装作确定就合进主分支。”这一段对话里有一个细节特别值——“每次提交代码前我必须能告诉你这段代码做了什么、依据是哪份 PRD”。我都没明说但 AI 自己推出了可追溯这件事的重要性。没有可追溯性问人这一档就废了——因为人接不住一份说不出’为什么改这行代码’的 diff。这就是对话驱动跟配置驱动最大的区别——配置驱动是你告诉它做什么对话驱动是你给它目标它告诉你怎么做、为什么这么做。配置出来的规矩是死的聊出来的判断是活的。兜底聊完再聊自学习——撞墙怎么记、记哪儿、怎么沉淀成下次能免试错的资产。对话示例 ⑧你“研发团队撞一次墙、爬一次、再撞一次——这些经历怎么沉淀下来不然下次又得从零撞”AI“这事我有思路——每修好一个坑就把’症状→原因→对策’写成一行记进一份手册。下次再遇到类似的事我先翻这份手册能免试错就免试错。”你“手册写在哪”AI“两份地方。一份写进项目复盘文档里——这样以后回看项目就能看到。另一份写进一个叫 SKILL.md 的文件——这是研发团队能’自己读’的文档下次干活前先读 SKILL它会告诉我们’这个坑上次怎么踩的这次别再栽’。”你“SKILL.md 跟普通文档有什么不一样”AI“普通文档是给人看的。SKILL.md 是给 AI 研发团队自己看的——它在工作流的最前面强制让商务/项目/产品/设计/架构/开发/测试/运维/运营先读再动手。你想要团队严格遵守 SKILL就在协作机制里加一条’动手前必须读 SKILL’的规矩。”你“这听起来像一种’类制度’。”AI“对。团队班规约束的是’什么绝对不能碰’删生产数据、自动部署SKILL 沉淀的是’做事怎么干更高效’代码规范、测试策略、部署流程。一硬一软互相补。”自学习聊到这咱们已经触及AI 研发团队怎么成长的核心了——它不是变聪明是变有经验。经验怎么存存进一份研发团队自己读得懂的 SKILL 里下次照着做。最后一件事——可观测性。对话示例 ⑨你“研发团队干活的每一步我怎么看得见我不可能一直盯着七个 agent。”AI“这事得有三层——”“一、埋点记录开发每次提交代码、测试每次跑用例、运维每次部署自动记一条’什么时间、谁、干啥、结果’。”“二、决策可见开发拒绝做一件事时‘这个技术方案不可行’必须告诉你为什么——是性能瓶颈、是安全红线、还是超出当前架构能力。”“三、过程可回放整次项目流能从头看到尾。商务接了啥需求、产品拆了啥 PRD、开发写了啥代码、测试报了啥 bug、运维咋部署的一条线串到底。”你“这三层是给我看的还是给研发团队自己看的”AI“主要是给你看的。你才能在出问题时第一时间定位是哪个环节、哪个角色、哪条规则出了问题。不然你就只能看着一份’看起来不对但说不出哪里不对’的交付物发呆。”到这里第三步聊完。你看——这一天里的这一步咱们没装一个 CI 工具、写一行监控代码、跑一次可视化。全是跟 AI 聊出来的设计——三台阶兜底、自学习沉淀 SKILL、三层可观测。为什么因为这三件事的本质不是技术是规矩。你把规矩讲清楚研发团队自己会照着做。五、第四步跟 AI 聊出装备上线前三步聊完研发团队有了班规、有了角色骨架、有了撞墙兜底。可还差一件事——怎么让这个研发团队跑起来不闷一个研发团队最怕的不是不会写代码——是闷。闷的意思是换台机器配不了环境、换个项目搭不起来、换个技术栈用不上。这一段聊两件事——借开源巨人和基座插件化。对话示例 ⑩你“研发团队干活肯定要查代码、跑测试、做部署——这些事咱们是不是得自己造一套工具”AI“别造轮子。外面有一堆现成的、公开的、被验证过的开源巨人——代码知识图谱、CI/CD 流水线、MCP 协议、AI 代码编辑器、自动化测试框架、容器编排平台——任何一个能用的组件都已经有开源版本。”你“那咱们要做什么”AI“站在巨人肩膀上划界——哪些用现成的、哪些自己加、哪些自己改。不自己造底座。”你“为什么不能自己造”AI“因为不值。你是 FDE你的活是陪客户把业务跑通不是把开源社区的工作重做一遍。你拿一周从零搭一套 CI/CD省不了你这一周的精力但你拿这一周陪客户跑通三个业务场景那就是真本事。”这一段对话里AI 自己说出了你拿一周从零搭一套 CI/CD省不了你这一周的精力但你拿这一周陪客户跑通三个业务场景那就是真本事——这个判断你自己想想是不是这个道理FDE 第一年最容易栽的坑就是我自己造一个。造不是本事借才是本事借的前提是你想得清楚哪些该借、哪些该自己造。第二件事——基座插件化。对话示例 ⑪你“我借了开源巨人下一步怎么让研发团队对外可迁移比如这个团队跑通了我想把它搬到下一个客户那——怎么搬”AI“基座插件化。”“基座是你不能动的部分——商务/项目/产品/设计/架构/开发/测试/运维/运营这九个角色、它们的协作规矩、技能库管理方式。这些解决’你这个研发团队长什么样、怎么运作’的根本问题。”“插件是基座上挂的能力——能查代码知识图谱、能跑自动化测试、能做容器部署、能发告警通知。一个插件一个能力加进来就用、拿掉就不影响别的。”你“这种设计的好处是什么”AI“可迁移、可交付。你换台机器、换套环境、换客户把基座插件原样搬过去就完了。每个客户的差异只通过增减插件表达不会污染到基座本身。”你“这跟产品化设计的逻辑有什么关系”AI“划清平台和用户的边界——哪些归平台基座、哪些归业务插件。这条线划清楚了你的 AI 研发团队就能从一个客户用到下一个客户从一个项目用到下一个项目。”到这里第四步聊完。这一天的最后几个小时咱们用两段对话把闷的问题解决了。你回头数数——这 11 段对话聊出了上一篇讲的全部十件内功红线、单一职责、可观测性、失败兜底、自学习、结构化目录、文档记忆、借助开源、基座插件化、交流式交互。一件没落下但全靠说话。聊到这里你脑子里大概率还有一句话“道理我懂了但我手头到底用什么工具把这支研发团队跑起来”我把自己这一年用得最多的开源社区作品挑了一组按四个档次给你——每一档你都先看这一档的核心问题是什么再挑一个上手就够不用全学。这节不是种草是给你一组可验证锚点你挑哪个都可以自己去仓库翻 README 验证不合适就换。第一档基础规范——给研发团队一份操作系统这是整个研发团队跑起来的地基——AI 运行时、规矩文件规范、技能库管理方式。OpenCode开源anomalyco/opencode——AI 协作工具的事实标准之一插件机制、技能库、命令行和网页界面都齐。你养的研发团队就跑在这上面。anthropics/skills官方规范anthropics/skills——Claude 体系下技能库的文件结构范例。你团队里每个角色怎么写、每个工具怎么描述照着这个走不会偏。第二档实战方法论——给研发团队一套做事章法地基有了但做事章法你得自己选。这一档都是社区沉淀下来的方法论——选一套就够不用全学。obra/superpowers开源obra/superpowers——强制 skill-check 的钩子机制AI 干活之前必须先读 skill、必须按 skill 走。十四件核心 skill 里我推荐先吃透brainstorming、“writing-plans”、“test-driven-development”、“systematic-debugging”、“verification-before-completion”——这五件是研发团队工作纪律的核心。mattpocock/skills开源mattpocock/skills——把对话就是命令的范式翻转为对话就是设计/grill-me让 AI 反复质疑你的方案、/grill-with-docs让 AI 边查文档边盘问你。这两个用法我自己天天用。第三档研发增强——给写代码、出方案、做交付的 FDE如果你做 FDE 经常要写代码、出技术方案、做系统交付下面这组工具能让你的工作流快一倍。JimLiu/baoyu-skills开源JimLiu/baoyu-skills——研发交付的插件集合。FDE 主用十一件——format-markdown、url-to-markdown、image-gen、compress-image、translate、markdown-to-html、youtube-transcript、electron-extract、diagram、danger-gemini-web、release-skills。这一套是我自己平时交付用得最顺手的从写技术文档、做架构图、压缩资源、翻译接口文档到发布一条龙。第四档可观测与兜底——让研发团队出问题时你能看见、能兜住最后一档是治理层那两件可观测性 失败兜底的工程化支撑。context7 MCP开源upstash/context7——把官方文档实时拉到 LLM 上下文里。研发团队遇到不熟的库不是凭记忆瞎调而是先去查最新的官方文档。github-mcp-server开源github/github-mcp-server——GitHub 全套操作的标准化协议接口。你团队要开 issue、要提 PR、要查仓库代码全走这一套。类似的代码知识图谱工具开源阵营里有不少——能把代码库的调用关系可视化、可检索。AI 团队改代码、改插件时能直接看到这个函数谁在调、改了会不会炸。playwright MCP微软开源microsoft/playwright-mcp——浏览器自动化。AI 团队要发文章、要填表单、要在客户系统里点点点全靠它。这份清单是基于 2026-06 的开源生态调研整理的。版本和 API 细节以各仓库 README 为准但哪些类别的工具必须用这件事跟具体仓库无关——你换一组名字同样成立。六、跑给你看AI 研发团队是怎么替你干活的11 段对话聊完你手头有一份班规、有一份角色清单、有完整的兜底协议、有可迁移的基座。但你心里一定有一句话“这听起来挺好可到底能不能跑”这一段我用一个真实场景跑给你看——让你养出来的 AI 研发团队从头跑一遍一个真实方案。场景是这样的——某个早上。一位零售连锁客户的 CIO 临时找上门“我们要替换现有那套 Excel 微信群的管理模式——进销存管理、日账盘点、交接班管理三套系统一齐上300 多家门店、加盟 自营混合。你能出一份整体方案给我们下周一的高管会吗周末两天定稿。”你坐电脑前跟你的 AI 研发团队说话——你“刚接个活——零售连锁客户要替换 Excel 微信群进销存/日账盘点/交接班管理三套系统一齐上300 门店、加盟 自营混合要一份整体方案下周一高管会用。你们自己看着分。”你说完这句话AI 研发团队自己接活、自己分工——商务先动、项目同步动、产品和设计跟上、架构定方案、开发和测试接力、运维兜底、运营看效果。9 个 agent 一条流水线把方案从头推到尾。商务先动对外“我先对接客户——把 CIO 的话拆成验收标准周末两天定稿 时间盒、下周一高管会 交付物定位、替换 Excel 微信群 改造对象。客户对接备忘存 01 客户资料/零售连锁 CIO/。”项目同步动对内“我拉项目骨架——三套系统并行开发、关键里程碑试点→推广→全量三阶段、资源估算开发 4 人 测试 2 人 运维 1 人 × 14 周。骨架存 02 产品文档/项目管理/零售连锁项目骨架/。”产品等商务 项目“我基于商务的对接备忘 项目的骨架出 PRD——三套系统的功能边界、用户角色总部/加盟商/门店店长/班次员工、业务流程进销存/日账盘点/交接班、验收标准。PRD 存 03 常见问题/零售连锁 PRD/。”设计等商务 项目“我基于商务的对接备忘 项目的骨架出 UI/UX——加盟商/直营门店的不同视图、移动端 PWA 适配当班店长用、统一账号登录流程。设计稿存 04 历史沉淀/零售连锁设计稿/。”架构等设计 产品“我基于 PRD 设计稿出技术架构方案——技术选型后端用 Node.js PostgreSQL加盟商隔离用 schema 分离、前端用 React PWA、事件总线用 Redis Pub/Sub。架构图画出三层架构接入层/业务层/数据层标清每个加盟商的 schema 隔离边界。接口定义RESTful API 规范 事件消息格式。架构方案存 02 产品文档/零售连锁架构方案/。”开发等产品 设计 架构“我基于 PRD 设计稿出技术方案 代码骨架——进销存SKU 主数据表 加盟商独立账套每个加盟商一个 schema 防数据隔离库存预警走事件驱动库存变更触发阈值检查。日账盘点每班结束事件触发汇总当班店长手机端走 PWA财务日清走定时任务。交接班管理班次表早中晚 任务清单模板未完成项用队列自动滚到下一班。集成层统一账号走 OAuth 2.0统一权限走 RBAC数据流通过事件总线打通。骨架存 03 常见问题/零售连锁代码骨架/。”测试等产品 设计 开发“我基于 PRD 设计稿 代码骨架出测试方案——功能用例覆盖三套系统核心流程、边界用例加盟商数据隔离、实时盘点、多班次交接、CI 自动化流水线。测试方案存 03 常见问题/零售连锁测试方案/。”运维等开发“我基于代码骨架出部署方案——三阶段部署节奏单店试点 → 区域推广 → 全量铺开、加盟商数据隔离部署每个加盟商独立 schema、监控告警库存异常/盘点延迟/交接班超时。部署方案存 04 历史沉淀/零售连锁部署方案/。”运营等项目 运维“我基于项目的里程碑 运维的部署节奏出运营方案——数据指标每阶段上线后要看什么试点期看稳定性、推广期看并发量、全量期看业务指标。用户反馈收集门店店长和加盟商的使用反馈分类优先级。持续优化根据数据和反馈推迭代计划。运营方案存 04 历史沉淀/零售连锁运营方案/。”没过多久——9 个 agent 各自汇报商务客户对接备忘就位——CIO 的验收标准拆清楚。项目项目骨架就位——三阶段里程碑 资源估算齐了。产品PRD 就位——三套系统功能边界 用户角色 业务流程 验收标准。设计UI/UX 就位——加盟商/直营视图分离、移动端 PWA、统一登录流程。架构技术架构方案就位——技术选型 三层架构图 接口定义。开发技术方案 代码骨架就位——数据模型、API、关键代码。测试测试方案就位——功能用例 边界用例 CI 流水线。运维部署方案就位——三阶段节奏 加盟商隔离 监控告警。运营运营方案就位——数据指标 用户反馈机制 持续优化计划。9 个 agent 共同交付 6 份文档客户对接备忘 / 项目骨架 / PRD 设计稿 / 架构方案 / 代码骨架 测试方案 / 部署方案 运营方案。今天先出部署方案这一份下周一高管会要用。你“部署方案这份我看看。”你打开部署方案标题、三阶段部署节奏单店 → 区域 → 全量、试点门店选择标准、加盟商数据隔离落地独立 schema 监控告警、多班次交接的技术落地队列滚动 定时任务全部到位。技术骨架对齐开发产出验收标准对齐商务拆解里程碑对齐项目骨架。你“行部署方案发我邮箱我下午两点给客户过目。剩下的别催你但今晚 7 点前给我看一眼。”——这就是 AI 研发团队替你干活的样子——商务/项目/产品/设计/架构/开发/测试/运维/运营 9 个 agent 自组织协作每个 agent 只管自己那一摊整支队伍一起把方案推出来。这是 FDE 的命根子——没有它你拿什么替客户交付你看这中间发生了什么——你跟 AI 研发团队说一句话9 个 agent 自己接活、自己分工——没说谁干什么他们自己分。商务、项目、产品、设计、架构、开发、测试、运维、运营各自只干一件事每个人守着自己的边界。撞墙了数据不对、需求跑偏、技术方案不可行、测试不通过——任何一个 agent 都可以打回上一个环节没人瞎编、没人胡来。所有产出落到结构化目录01 客户资料/ 02 产品文档/ 03 常见问题/ 04 历史沉淀/下次类似项目直接翻出来复用。你只在两件事上拍板部署方案行、今晚 7 点前给我看一眼。这中间你跟 AI 说了多少句话加上部署方案行那句一共 3 句。这就是养团队最终的形态——你不是 AI 的操作员而是个一句话就能调度整支研发团队的人。而这一切——班规、研发团队、目录、兜底、基座、插件——没有一行代码、一个配置文件是你自己写的。全是一天对话里你一句、他们一句聊出来的。七、写在最后回到开篇那句——“团队是沟通出来的不是手动创建的”。上一篇我们讲了为什么。这一篇我们做到了——一天11 段对话搭出一支 AI 研发团队。你回头看会发现整个过程没有任何魔法。它靠的就是一件最朴素的事你愿不愿意把班规、边界、流程、判断标准——这些你脑子里的隐性规矩——讲给 AI 听。你讲的过程就是把隐性变显性的过程。你讲完规矩就长出来了。这其实就是这个专栏一路反复念叨的那句话的最直接落地人立法AI 执行体系审计。这里的法不是别人替你写好的是你自己跟 AI 聊出来的。你聊出来它照着做它做的时候撞墙撞出来的经验再聊回给你你把经验整理成 SKILL它下次照着做——人定的法在循环里越来越厚AI 在循环里越来越稳。到这你可以喘口气了——你 FDE 第一年最难的那道坎已经过去了。接下来的事就是拿你养出来的研发团队出门见客户。第一个项目可能跑得磕磕绊绊但班规在那、研发团队在那、兜底在那——它跑不烂。未来真正会用 AI 的人不一定是把每一条班规、每一道兜底都想得最周全的人而是那种愿意把脑子里的隐性规矩讲给 AI 研发团队听、敢让它在边界内自己跑、自己长本事的人。你这一天练的不是配置能力是沟通能力——跟一支不会累、不会忘、但需要你讲清楚的研发团队长期对话下去。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline