企业官网建设流程全解析

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上粗算过：

为什么总消耗反而低？全能助手需要把大量历史聊天内容反复塞进上下文，越到后面越贵。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 Don'ts

如果你也想试，我的建议是从小规模开始，不要一上来就搭23个角色。

先选5到8个最痛的角色，比如需求侦探、接口契约员、测试执行者、代码评审官。把它们的输入输出定义清楚，跑通一两个真实需求，再慢慢扩充。角色数量增长必须跟着实际痛点走，比如文档总被遗漏，再加文档编年史家；线上事故定位太慢，再上值班诊断员和复盘机。

然后要记住几条硬规矩：任何角色都不能直接合并主干；任务卡必须写清输入输出和验收标准；角色定义文件必须独立存放；每个角色的产出物都要归档。这些规矩比选什么模型、写什么提示词更重要，因为它们决定了整个工作流是不是可审计、可回滚。

8.3 我对这套工作流未来演进的判断

我自己的体会是，gstack这类多角色AI工作流，最终会从"角色编排"走向"能力协议"。角色不再是一个个固定的Prompt名字，而是一组可复用的能力接口：能写契约、能跑测试、能生成监控配置。将来换模型、扩展新角色，都只需要改接口实现，不需要推翻整个流程。

对我而言，这不是一个用来秀技术的工作流，而是一种更接近真实研发协作的方式：让AI像团队成员一样，各管一段上下文，各交一份工件，再由人类负责最终拍板。如果你愿意在一开始多花点时间把角色边界划清楚，后面省下来的返工成本会远超你搭建它时付出的那几天。