1. 起因在一个AI干完全栈翻车之后1.1 最开始的全能助手方案为什么坚持不下去今年年初我在一个叫某跨平台系统的中型项目上尝试了一种看起来很省事的开发方式把需求、架构、代码、测试、发布全丢给同一个大模型助手。Demo阶段确实爽一条需求贴进去它能把数据库表、接口文档、前后端代码一股脑生成出来。但真进了持续迭代的状态问题就接二连三地冒出来。首先是上下文漂移。一个新功能开发到第三天模型已经开始忘了第一天定的模块边界。我明明在需求里写过订单状态只在服务端变更它在接口层却擅自加了一个允许客户端直接修改状态的入口。每次都得把之前的结论反复粘回去既浪费token也消耗耐心。其次是审查成本。一个全能助手输出的代码看起来都挺完整但里面混着多种风格有的文件用了A方案另一个文件又用B方案。代码评审其实变成了我一个人从头到尾盯数据库设计、接口契约、前端交互、后端安全、产品规则全部要我自己管。人不是这么设计的AI的上下文窗口也不会因为能聊很久就自动变强。后来我认真复盘发现核心问题不在于这个AI不够聪明而在于我给了它一个不可能完成的任务一个人要同时拥有产品经理、架构师、前端、后端、测试、运维的全部记忆还要在每一步都保持状态一致。这就像让一个员工既当项目经理又当开发又当测试还连续工作一周不换人。于是我决定反过来想团队为什么能把复杂度稳住因为每个成员只承担一个角色只带一部分上下文。那为什么不能把同一套逻辑搬到AI工作流里1.2 从团队分工里得到的灵感角色即上下文真实研发团队里没有人会从需求评审一路盯到线上监控。产品经理交付PRD架构师画模块图前端拿接口契约写页面后端写服务端逻辑测试照着验收标准写用例SRE配置告警。每个人手里都只有自己这一层的上下文但最终能拼出一个完整系统。这个现象给我一个关键启发对大模型来说角色的本质不是性格不是语气而是上下文范围。角色定得越清晰上下文边界就越明确。比如接口契约员根本不需要知道页面按钮长什么样它只需要知道数据模型、业务语义、调用方字段需求。界面构建者也不需要读完整后端业务代码它只关心接口契约和设计稿。上下文一旦被切成小块每个AI角色的一次性会话反而更聚焦产出质量更高幻觉也更少。我把这套思路整理成了gstack的第一条设计原则角色即上下文。每个角色拥有独立的身份定义、输入工件、输出工件以及一套专属的检查清单而不是一个大Prompt里塞满所有岗位说明。1.3 gstack这个名字从哪来23这个数字怎么定的gstack这个名字g可以理解成group也就是一组角色也可以理解成guardian因为每个角色都在上下环节点上做守护。本质上它是一个由多个AI角色协作、覆盖从需求到运维的全栈开发工作流框架。名字里的stack强调的是角色栈而不是单纯指语言或框架。23个角色不是一开始拍脑袋定的。我先从自己最熟悉的需求→设计→编码→测试→发布→运维全流程里列出15个关键节点再把每个节点拆成独立职责。过程很自然需求澄清拆成收集需求和定义验收标准代码实现拆出前端界面状态管理后端服务接口联调光一个测试就能拆出设计用例执行测试评审代码三份活儿。拆完发现膨胀到27个合并了几个明显重叠的比如把性能检查和压测执行合并成性能刺客把日志配置告警配置链路追踪配置统一交给监控配置员最后稳定在23个。23这个数字挺有意思它不是角色越多越厉害而是刚好覆盖了日常开发里最常出现的工作类型。你复制这套方案时完全可以按团队规模增减关键是每个角色都能回答三个问题我负责什么我的输入是什么我的产出交给谁。2. gstack的底层逻辑按工作流节点而不是技术栈划分角色2.1 全栈开发工作流里的12个关键节点gstack的第二个设计原则角色按工作流节点划分不按技术栈划分。常见做法是按技能树分角色一个前端专家、一个后端专家、一个数据库专家。但放到AI协作里这样分有一个麻烦前端专家依然要读取大量后端契约后端专家依然要看需求背景角色边界还是糊的。更稳定的划分维度是这个环节要产出什么工件。我把研发流程拆成12个关键节点每个节点有明确的输入工件和输出工件。需求阶段输出用户故事和验收标准设计阶段输出模块方案、数据模型、接口契约开发阶段输出代码和测试发布阶段输出构建产物、发布计划和监控配置运营阶段输出告警规则和事故复盘。12个节点不是单向流水线而是一张依赖图有的节点可以并行有的节点需要回头反哺上游。实际运行中任务卡在节点之间流转而不是所有AI围着一个对话框聊天。下面是一张我常用的节点与角色对应表方便理解23个角色是怎么挂到节点上的阶段关键节点代表角色需求需求澄清需求侦探、交付规划师设计方案设计方案架构师、体验草图师设计数据建模数据建模师设计契约定义接口契约员开发任务拆分交付规划师开发界面实现界面构建者、状态管理师、样式调和师开发服务端实现后端服务实现者、接口联调师测试用例设计单测构筑师测试执行验证测试执行者、代码评审官、重构法师发布安全检查安全检查员、性能刺客发布构建发布发布指挥、回归巡检员、文档编年史家运维监控值守监控配置员、值班诊断员、复盘机这张表不是标准答案。不同项目的节点粒度可以完全不同如果做内部工具可能不需要体验草图师如果做金融系统安全审计还得再拆两倍。关键是先在纸上画出你知道的节点再给节点分配角色而不是先定义一堆角色再硬套流程。2.2 角色和节点对应为什么有些节点需要2-3个角色一个节点只给一个角色看起来高效实际容易变成既当运动员又当裁判。接口契约节点如果只有一个人写契约没人校验契约和实际代码是否一致交付后联调阶段一定出问题。所以gstack里会有意识地给关键节点配置生产者、验证者和协作者三种角色。拿测试节点举例我拆出了单测构筑师、测试执行者、代码评审官。单测构筑师的任务是写用例它天然乐观容易顺着实现代码的思路走测试执行者则负责冷酷地跑结果不允许解释只允许报告代码评审官从可维护性角度找逻辑漏洞不和实现者共享我写了什么的上下文。三个角色互相独立才能减少确认偏误。有些节点则需要角色之间做接力。以发布节点为例发布指挥负责执行构建和上线脚本回归巡检员负责发布前的冒烟测试监控配置员负责发布后的指标曲线。三者都围绕发布这个节点但关注点完全不同一个关心能不能装上一个关心业务通不通一个关心系统稳不稳。把三个角色压成一个编排会简单很多但线上事故发生时一个人又跑脚本又盯指标又复盘效率和可靠性都不够。2.3 角色能力矩阵哪些角色负责思考哪些角色负责产出哪些负责把关角色分得细就必须给它们分类否则调度就是一笔糊涂账。我在gstack里给每个角色打了一个标签产出型、校验型、协同型。产出型角色负责生成工件比如方案架构师产出架构说明后端服务实现者产出代码校验型角色负责挑错比如代码评审官、回归巡检员协同型角色负责把不同角色的产出粘在一起比如接口联调师、交付规划师。这个分法非常关键因为它直接决定了角色权限。校验型角色默认没有写入权限它只能生成问题清单产出型角色可以生成diff但不能直接合并到主干协同型角色可以修改任务卡却不能越过设计决策。这样一来23个角色再怎么跑来跑去最终的合入点仍然被人类或确定性流程牢牢控制住。后来我复盘这套矩阵真正的价值不是把任务分类而是让每个角色知道自己几斤几两。AI角色之间不会真的闹脾气但如果权限不清就会出现代码评审官顺便帮你把代码改了这种越权行为。矩阵明确之后角色之间的权力边界和人类团队里的岗位说明书一样清晰协作自然就顺了。3. 23个AI角色全景清单从需求分析师到事故守卫3.1 需求与设计阶段的6个角色需求阶段一共安排了6个角色覆盖从一句话想法到可执行任务卡的完整距离需求侦探把产品想法、用户反馈、旧版日志转成结构化用户故事。它必须列出验收标准、边界条件、歧义清单最后输出需求卡片和待确认问题。方案架构师基于需求卡片和现有代码结构做模块拆分、技术选型、风险清单。它的产出不是详细设计而是架构决策记录简称ADR。数据建模师负责ER模型、索引策略、迁移方案、数据归档策略。所有这个字段要不要冗余这个表要不要加唯一约束的问题都由它回答。接口契约员定义API路径、请求参数、响应结构、错误码、兼容性规则。它只定义契约不实现逻辑。体验草图师产出页面线框、交互说明、可访问性要求。它不写代码但要把用户走到哪一步会遇到什么状态写清楚。交付规划师把需求卡片拆成任务卡排优先级、依赖关系、验收项。它不决定技术方案只决定先做什么、谁需要什么输入。需求阶段放6个角色原因是前期返工成本最低但影响最大。如果需求侦探没写清楚导出文件超过10万行时要分页后面的架构、契约、后端实现全部要返工。前期每个角色多花一次澄清后期就能少改十个文件。3.2 编码与测试阶段的9个角色进入编码和测试阶段角色数量最多一共9个界面构建者依据线框和接口契约实现页面组件。它最关心组件结构和交互逻辑不负责全局样式。状态管理师定义客户端数据流、缓存策略、错误态。它要回答这个页面刷新后状态从哪来请求失败时界面展示什么。后端服务实现者写核心业务逻辑保护业务不变量。它不允许跳过参数校验也不允许在Service层堆SQL。接口联调师连接前后端处理字段映射、类型转换、时序问题。它经常产出适配层代码和映射表。样式调和师统一设计变量、间距、主题、无障碍对比度。它不和业务逻辑打交道只保证视觉系统一致。单测构筑师设计并编写单元测试、桩数据、边界条件。它的职责是覆盖需求里说的和边界上可能发生的。测试执行者运行测试套件生成覆盖率和失败清单。它只负责报告不负责修代码也不允许解释失败原因。代码评审官按团队规范审查变更输出问题清单和修改建议。它关注逻辑漏洞、可读性、模块边界但不会直接改文件。重构法师消除重复代码、优化模块边界、整理依赖关系。它生成建议diff但必须由人类或CI确认后才能合入。这9个角色看起来多其实构成了一条完整链路实现→联调→样式→单测→执行→评审→重构。每个角色只盯一件事所以每次Prompt都足够短短到不会触发模型在大上下文里迷失自我。3.3 发布与运营阶段的8个角色发布与运营阶段安排8个角色它们的产出不再只是代码而是可审计的配置、报告和流程安全检查员扫描依赖漏洞、密钥泄露、越权配置。它输出安全报告并且会标记禁止合入级别的严重问题。性能刺客做压测、耗时分析、慢查询定位。它不负责优化只负责找到最值得优化的前三个点。文档编年史家更新README、接口文档、变更日志。它和代码评审官同时工作防止代码改动和文档脱节。发布指挥执行构建、打标签、跑发布脚本、维护回滚计划。它必须回答如果发布五分钟内指标异常回滚到哪个版本。回归巡检员发布前跑冒烟测试和核心链路检查产出Go/No-Go报告。它不会因为后面还有测试就放行。监控配置员配置日志、指标、告警规则、看板。它要确保每个关键业务动作都有对应的可观测信号。值班诊断员在告警或用户投诉后从日志和链路追踪里定位根因。它输出的是问题可能在哪、下一步去翻哪个系统。复盘机把事故时间线、影响面、行动项整理成文档并沉淀为团队知识。它不允许追责只允许定义改进项。安全、性能、文档、发布、监控、诊断、复盘这8个角色决定了代码上线之后能不能睡得着觉。它们不是额外的负担而是把之前靠人肉记忆完成的运维工作变成了有据可查的工件。3.4 每个角色的职级与豁免策略23个角色里没有一个是大总管。我给每个角色都配了职级和豁免规则。职级决定它能做什么初级角色只能产出分析中级角色可以产出diff高级角色可以修改任务卡。豁免规则决定它不该做什么代码评审官豁免写代码测试执行者豁免参与修复方案的决策文档编年史家豁免修改产品策略。这套设计借鉴了权限最小化原则。角色之间不能互相替代也不能越级拍板。真正需要跨角色协同的时候由确定性流程把上一个角色的输出物转成下一个角色的输入物而不是让某个AI角色兼任别人。4. 角色协作的核心机制消息总线与上下文隔离4.1 用结构化任务卡在角色间传递信息如果只是给AI加一堆角色名但没有消息传递机制那它们依然相当于在同一个黑板上写写画画。gstack里的核心消息单位叫任务卡。每张任务卡包含任务ID、执行角色、输入工件、输出工件、约束条件和完成标准。角色只读自己需要的那部分只改自己该改的那部分。下面是一张我用过的任务卡示例task_id: T-0042 role: interface_contracter inputs: - design/layouts.md - data_model/er_v3.md outputs: - contracts/api_orders_v2.md constraints: - 所有接口路径以 /api/v2/ 开头 - 错误响应必须使用统一结构 definition_of_done: - 每个接口包含请求/响应示例 - 每个字段标记类型、必填、校验规则 - 列出至少5个可预期错误码 consumer: backend_implementer为什么用任务卡而不是直接让两个AI对话对话是隐式的你很难限制AI到底该听谁的、该忽略谁。任务卡是显式的所有角色必须围绕同一个工件、同一套约束工作。它相当于给每个角色递了一张看得懂、能验收的工单而不是一句你顺便看看。4.2 上下文隔离的三种实现方式任务卡只解决了传什么还解决不了AI到底看到多大多长的上下文。我在gstack里做了三层隔离。第一层是文件即上下文。每个角色只接收任务卡里列出的文件列表不接收整个仓库。比如接口契约员只看到数据模型和需求卡片不会看到前端组件代码。第二层是会话级隔离。每个角色用独立的一次性会话不保留之前所有对话历史。开始新任务时就清空记忆只带着任务卡和输入工件重新推理。这样能避免AI越聊越疲惫造成的质量衰减。第三层是知识库分层。把团队规范、代码风格、工具手册拆成可以被引用的小块而不是整体塞进每个Prompt。比如界面构建者需要组件库规范但不需要发布脚本模板发布指挥需要回滚手册但不需要前端组件写法。这三层隔离做下来最直观的变化是单次Prompt的长度大幅缩短。上下文一短模型对关键信息的注意力就集中了产出物的稳定性也会好很多。4.3 编排器如何决定下一个该谁上场23个角色之间不能靠念咒语调度必须有一个确定性的编排器。我特别强调确定性因为如果调度逻辑也交给AI整个流程就变成了一场不可预测的对话。gstack的编排器更像一个依赖解析器它读取任务卡里的依赖字段找出哪些角色可以并行、哪些角色必须等上一个角色完成。举一个具体例子新功能进入开发阶段后界面构建者和后端服务实现者可以并行启动因为它们都依赖接口契约员但接口联调师必须等两边都产出代码之后才能上场。安全检查员和性能刺客可以同时跑但它们都要等后端实现者完成。编排器还负责跳过不必要的工作。如果某次改动只涉及前端样式数据建模师、接口契约员、后端服务实现者这一整条链都不需要被唤醒。角色越多越需要靠依赖关系做裁剪否则成本会膨胀到让人怀疑人生。5. 我的gstack落地配置提示词模板与工具链选型5.1 一套可复制的角色提示词框架23个角色如果每个都写一套完全不同的提示词维护成本会很高。我的做法是统一模板每个角色只填六个部分角色、使命、输入、输出、约束、完成标准。这套模板并不花哨但足够让模型搞清楚边界。# 角色{role_name} ## 使命 {一句话说明这个角色为什么存在} ## 输入 - {输入工件1} - {输入工件2} ## 输出 - {必须生成的工件} ## 约束 - {不允许做什么} - {必须遵循的规范} ## 完成标准 - {验收项1} - {验收项2} ## 禁止行为 - 不要修改{范围外的文件} - 不要代替{其他角色}决策拿接口契约员举例实际填出来是这样的# 角色接口契约员 ## 使命 把稳定的业务语义翻译成前后端都能遵守的接口契约。 ## 输入 - 数据模型文档 docs/data_model_v3.md - 需求卡片 tasks/T-0042.md ## 输出 - 契约文件 contracts/api_orders_v2.md ## 约束 - 所有接口路径以 /api/v2/ 开头 - 错误码使用统一错误结构 - 不实现业务逻辑只定义契约 ## 完成标准 - 每个接口有请求/响应示例 - 每个字段有类型、必填、校验规则 - 列出至少5个可预期错误码 ## 禁止行为 - 不要修改数据模型文档 - 不要替后端服务实现者写SQL这套模板最大的好处是可审计。每个角色到底被要求做什么、不允许做什么都写在文件里评审的人不用去猜。5.2 工具链从本地脚本到CI的集成方式我把gstack实现成了一套非常朴素的脚本目录和目录约定而不是装一堆新平台。repo/ roles/ # 角色定义目录每个角色一个md文件 cards/ # 任务卡目录 artifacts/ # 角色产出物按任务ID归档 scripts/ dispatch.sh # 读取角色定义任务卡调用模型 run_test.sh # 触发测试执行者 release.sh # 触发发布指挥dispatch.sh做的事情很直接解析任务卡拼出该角色的Prompt把输入工件内容注入调用大模型API然后把返回结果写入artifacts。整个过程可以被任何人查看和重跑不存在AI在黑箱里自己决定了一切的情况。CI的集成方式同样简单代码推送到分支后CI先跑静态检查和单测只有通过才触发文档编年史家的更新任务合入主干前必须有人工确认或确定性脚本二次校验。角色可以生成一切内容但合入这个动作始终是流程控制不是AI控制。5.3 异步与批处理的组合模式23个角色全部同步调用会很浪费时间。我做了两类优化异步并行和批量合并。异步并行的例子是界面构建者、后端服务实现者、样式调和师可以同时开三个任务分别跑在不同的工作目录里。只要它们不共同修改同一个文件并行就是安全的。批量合并的例子是多个变更都通过测试后文档编年史家可以一次性汇总而不是每个PR都触发一次文档更新。还有一个成本控制技巧按改动范围裁剪角色。如果卡里标注前端样式变更监控配置员就不需要上场。gstack里的编排器会维护一张触发条件表比如改动类型必须触发的角色可跳过的角色后端接口变更接口契约员、后端服务实现者、接口联调师、测试执行者体验草图师、样式调和师纯前端样式变更界面构建者、样式调和师接口契约员、数据建模师发布配置变更发布指挥、监控配置员、回归巡检员单测构筑师、重构法师触发条件表写清楚之后角色看起来有23个实际一次任务通常只唤醒5到9个。这是控制成本和避免上下文污染的关键。6. 实测效果效率提升、质量变化和成本账6.1 前后对比完成同样功能的不同路径我拿订单模块增加导出功能做过一次对比。老路子是这样的我把需求贴进一个超长会话让同一个AI助手从数据模型一路干到前端按钮中间我不断纠正它遗忘的需求全程大概需要两个工作日人工干预五六次。gstack版本则是需求侦探先产出需求卡片接口契约员定义导出接口后端服务实现者生成导出逻辑界面构建者加了一个按钮入口单测构筑师补齐用例测试执行者跑完整套测试文档编年史家更新接口文档。我只需要在两个节点介入看一次接口契约合入前做一次代码评审。在一个模拟项目X上这段流程从两天左右压缩到一天以内人工干预从五次降到一两次。这个数字不算夸张因为真正省下的时间不是AI写得快而是不用反复纠正AI忘记的上下文。6.2 23个角色带来的收益不只快除了速度质量层面的变化更值得关注。最明显的是代码风格一致性以前同一套系统里会混着方法A放上面和方法A放下面两种风格现在样式调和师和代码评审官分别盯住了视觉与代码规范合入后的代码像是一个人写的。安全性也有改善。以前密钥偶尔会被无意提交到仓库现在安全检查员会在合入前拦截一次虽然只是少了一次事故但整个人都踏实了。测试方面单测构筑师和测试执行者分开后覆盖率报告不再是看起来很高因为测试执行者会严格跑失败用例而不是听实现者解释。还有一项不太容易被量化的收益信任。每个角色都产出独立工件评审者可以直接看接口契约、看测试报告、看发布runbook不用翻一整段聊天记录找当初到底怎么定的。这种可审计性比效率数字更值钱。6.3 成本构成和Token消耗怎么压有人一听23个AI角色就担心成本变成23倍。实际不是这样。我给角色做了专门裁剪后一个功能的Token总消耗反而比一个全能助手反复聊三天要低。我在模拟项目X上粗算过模式单角色平均上下文总Token消耗人工干预次数全能助手120k-180k约900k5-6gstack20k-40k约650k1-2为什么总消耗反而低全能助手需要把大量历史聊天内容反复塞进上下文越到后面越贵。gstack则让每个角色只看自己需要的小块虽然调用次数变多但单次成本低。真正要控制的是同一件事触发多个角色重复做所以我特别依赖触发条件表。只要裁剪逻辑稳定23个角色带来的不是成本爆炸而是更可控的支出分布。7. 真实踩坑记录角色一多乱成一团7.1 第一个坑所有角色共享同一个Prompt仓库我最早把23个角色定义写在一个大Prompt文件里dispatch时直接把这个文件整体塞给模型。结果很快出问题让代码评审官审查一段代码它提交的内容里既有评审判定又偷偷写了新的接口定义还加了一句如果按新的字段约束这里建议改动。这显然不是代码评审官该干的。我一开始以为模型能力不行换了模型还是类似表现。后来我做了完整的排查固定同一段输入和同一张任务卡连续跑五次三次出现越权然后把Prompt换成只包含当前角色定义问题消失了。定位到这里就明白了全量Prompt会让模型同时看到23个潜在身份它根本不知道此刻应该只做谁。修复方案是把角色定义拆成一个角色一个文件dispatch时只注入当前角色定义和共享风格指南。另外我在Prompt里明确加了一句你不是其他角色也不要建议其他角色的事务。为了保证不复发我还在CI里加了一个角色纯度测试任何角色输出里出现其他角色专有动作词就算失败。7.2 第二个坑测试角色和实现角色互相甩锅角色分得越细甩锅空间就越大。有一次后端服务实现者交付了代码测试执行者跑出一堆失败实现者说是测试用例写错了测试执行者说实现没按契约来。两边都振振有词我作为人类也一时分不清。分析根因时我发现问题不在模型而在流程实现者和测试者没有共享同一份验收标准。实现者理解的完成是主流程跑通测试者理解的完成是所有边界条件都覆盖。它们各自基于一套我不知道的标准在工作自然会冲突。修复方式是在每张任务卡里强制加入验收标准来源和definition_of_done并且要求实现者和测试者都引用需求侦探产出的原始需求卡片。当两边冲突时以契约测试为准不允许任何一方私下修改验收条件。这个坑让我意识到角色化只是手段真正让协作成立的是公开一致的定义。7.3 第三个坑编排器给了角色过大的决策权还有一次我允许重构法师在单测通过后自动合并diff。它确实重构了代码单测也过了但上线后出了事故。回溯发现它把某个回调函数的参数顺序改了调用方没有同步更新而当时那段路径没有单测覆盖所有检查都绿灯。问题出在我给了角色过大的执行权限。重构法师自认为有权推进重构于是在测试通过这个信号下做了自动合入。修复方案很干脆任何AI角色都只能生成diff不能合并到主干所有diff统一进入PR分支由人类审批或确定性CI检查通过后合入。AI可以做99%的工作但合入决策必须有人类在场。这个坑让我把决策权和执行权彻底分开。权限设计不是越小越好而是谁决定、谁执行、谁校验必须三权分立。AI角色可以是执行者但决策链路里一定要保留一个人的确认点。8. 现在还在演进的部分和我的使用建议8.1 当前版本做不到的几件事gstack不是银弹它有几件明显做不到的事。第一它处理不了超大代码库的全局理解。每个角色只看切片遇到跨模块的大重构时切片上下文反而会限制它的判断。这种场景我仍然需要人先用架构思路搭骨架再让角色补肉。第二角色没有真正的长期记忆。今天让代码评审官记住的结论下一个任务开始后它就忘了。任务卡能记录当时的结论但不能形成团队那种连续的默契。所以重要的架构决策必须落到文档里不能只靠角色会话。第三多角色之间的讨论容易变成表面功夫。如果某个决策需要两个角色来回交锋AI角色的对抗性讨论往往不如一个懂业务的人直接拍板高效。现阶段我还是把讨论收敛成由人类主持的评审会角色只负责提交各自的证据。8.2 给小团队/个人的Dos and Donts如果你也想试我的建议是从小规模开始不要一上来就搭23个角色。先选5到8个最痛的角色比如需求侦探、接口契约员、测试执行者、代码评审官。把它们的输入输出定义清楚跑通一两个真实需求再慢慢扩充。角色数量增长必须跟着实际痛点走比如文档总被遗漏再加文档编年史家线上事故定位太慢再上值班诊断员和复盘机。然后要记住几条硬规矩任何角色都不能直接合并主干任务卡必须写清输入输出和验收标准角色定义文件必须独立存放每个角色的产出物都要归档。这些规矩比选什么模型、写什么提示词更重要因为它们决定了整个工作流是不是可审计、可回滚。8.3 我对这套工作流未来演进的判断我自己的体会是gstack这类多角色AI工作流最终会从角色编排走向能力协议。角色不再是一个个固定的Prompt名字而是一组可复用的能力接口能写契约、能跑测试、能生成监控配置。将来换模型、扩展新角色都只需要改接口实现不需要推翻整个流程。对我而言这不是一个用来秀技术的工作流而是一种更接近真实研发协作的方式让AI像团队成员一样各管一段上下文各交一份工件再由人类负责最终拍板。如果你愿意在一开始多花点时间把角色边界划清楚后面省下来的返工成本会远超你搭建它时付出的那几天。