明智的开发人员不会通过提出巨大的拉取请求来启动新项目。他们通过集思广益、队友讨论、原型设计、图表、提案、ADR、MR/PR 和 GitOps（每次更改时都会使用审核机器人）进行工作，并且当规模需要时，Workstation 的多代理架构可以组建一支出色的开发团队，快速交付生产级工作。
1. “明智”对于新项目意味着什么
智慧是尽早学习廉价的知识，以及晚时罕见地犯下昂贵的错误。下面的序列是有序的，因此每一步都会缩小下一步的爆炸半径：
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. 头脑风暴
在花时间与他人相处之前，先花 30-90 分钟独处：
- 结果 ——当我们完成后，对于企业来说必须有什么是正确的？
- 约束条件 ——时间、合规性、平台、技能、预算。
- 非目标 — v1 明确不包含的内容。
- 风险 — 数据、安全性、性能、锁定、操作负载。
- 成功指标 — 选择两个（例如延迟+采用，或成本+错误率）。
把它写在下面 docs/ideas/。不成文的头脑风暴消失了。
3.与同事讨论
邀请最小的有用圈子：同行实施者、相邻系统的所有者以及安全/SRE（当风险需要时）。
- 时间范围（25-45 分钟）。以决定或开放性问题结束。
- 强制选项：A、B、推迟——不是含糊的协议。
- 指派一名抄写员；该说明为提案奠定了基础。
- 将不适视为 ADR 的风险——没有沉默的否决权。
如果有人关闭循环，异步 RFC 就很好。
4. 原型设计
当不确定性很高时会出现峰值。明智的规则：
- 将其标记为尖峰；设置日历停止点（通常为 1-3 天）。
- 将其放在一次性树枝上或
spikes/— 请勿抛光。 - 写下你所学到的十个要点（尤其是失败的事情）。
- 决定：推广、重写或放弃——永远不要“悄悄地成为产品”。
5. 图表
通常三个草图就足够了：
| 图表 | 答案 |
|---|---|
| 上下文（C4 L1） | 谁在和什么说话？信任边界？ |
| 顺序 | 快乐之路+一条失败之路 |
| 部署 | 它运行在哪里；配置和秘密流程 |
将 Mermaid 或 SVG 存储在提案旁边。 ADR 发生变化时进行更新。
6. 提案
保持 RFC 简短（1-3 页）：问题、选项（至少两个）、建议、影响（安全/成本/操作）、部署和回滚、开放性问题。获得批准后，将决定转化为 ADR。
7.ADR——架构决策记录
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
将 ADR 保存在 git 中（docs/adr/）。从 PR 链接它们。取代而不是重写历史。
8. MR 和 PR——交付单位
先生 （合并请求）和 公关 （拉取请求）是相同的想法：可审查的变更集。
- 小（优选 <400 行有意义的差异）；每次变更都有一个意图。
- 描述：为什么、如何测试、风险、回滚。
- 链接：票+ADR+图表。
- 尽早起草以获取反馈；如果没有书面例外，切勿强制合并红色 CI 或高严重性机器人发现。
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot——保护生产的自动评论
审阅机器人是自动的第一审阅者。它不会取代人类；它预先加载了无聊和危险的内容，因此开发人员可以将时间花在设计和产品风险上。
9.1 应评论什么
- 安全性：注入、授权差距、秘密泄露、不安全的默认设置
- 正确性：空路径、竞争、损坏的迁移
- 测试：缺少新分支的覆盖范围
- API/合约：在没有版本升级的情况下进行重大更改
- Ops：缺少超时、无限制重试、非幂等写入
9.2 它如何简化开发人员的生活
- 作者在几分钟内打开 PR → 机器人评论。
- 作者在询问人类之前修复或回复。
- 人类阅读机器人摘要+重点关注架构和爆炸半径。
- 更少的尼特回合；生产中逃逸的步枪较少。
9.3 保持机器人有用的策略
- 严重性：blocker / should-fix / nit — nits 不得阻止合并。
- 忽略生成的路径；每月调整误报。
- 需要人工批准
auth/,infra/、IAM 和资金路径。 - 永远不要让机器人成为生产关键服务的唯一审核者。
通过 PR 差异连接 SaaS 机器人（例如 CodeRabbit）、Cursor Bugbot 或自定义 Action + LLM。分层 lint → SAST → LLM 以获得最强的姿势。
10. 生产级质量的 GitOps 最佳实践
所需的状态存在于 git 中。协调器（Argo CD、Flux 等）使集群匹配。促销是合并；回滚是恢复。
- 单独的应用程序代码和环境配置（或清除
envs/dev|staging|prod覆盖）。 - 没有临时的
kubectl apply刺激作为幸福的道路——仅打破玻璃，经过审核。 - 渐进式交付：自动同步较低的环境；产品的门控同步。
- 对产品中的可变标签进行图像摘要。
- 用于特权和注册表的策略即代码 (OPA/Kyverno)。
- 同步后观察；练习回归。
代码质量不仅是干净的功能，而且 变革如何进入生产.
11. 工作站多代理架构——打造优秀的开发团队
一个明智的开发人员仍然需要杠杆。 Workstation 的多代理架构（Agentic AI 工作站包和 OpenClaw for Business，您需要具体或专门的代理团队）让您 自动组建开发团队 围绕业务简介——而不是静态的组织结构图。
11.1 组合循环
- 简短的 ——利益相关者的成果、限制、SLA。
- 撰写 — 将角色映射到技能（规划者、构建者、审核者、运营者、合规者）。
- 引导程序 — 代理运行时 + MCP 工具 + 内存 + 审计跟踪。
- 执行 — 代理拉动工作，根据规范/AC 实施，对每个步骤进行小型审查。
- 审查直至干净 — 审阅机器人 + 审阅代理 + 人门。
- 船 — GitOps 促进重要的环境。
11.2 角色图（人+代理）
| 角色 | 代理确实 | 人类仍然拥有 |
|---|---|---|
| 规划师 | 来自 Spec 的史诗、故事、AC | 优先级和范围缩减 |
| 建设者 | 并行实施、测试 | 硬边缘域判断 |
| 审稿人 | 规范合规性、审核机器人分类 | 架构和产品签核 |
| 行动 | GitOps 同步、SLO 监视、草稿回滚 | 上线和事件指挥 |
| HITL门 | 升级有风险的写入/支出 | 批准或拒绝 |
11.3 为什么这可以打造优秀的团队
- 专业化 — 每个代理人都有一份工作；当角色不模糊时，质量就会提高。
- 无混乱的吞吐量 — 单个规格和审查机器人背后的并行构建者。
- 决策的共享记忆 — ADR + Spec + PR 历史成为团队的长期记忆。
- 与人类相同的门 — CI、Review Bot、CODEOWNERS、GitOps — 代理不会绕过生产纪律。
- 业务速度 — 花费数小时来组建一支有能力的团队，而不是花费数周时间来为每个尖峰招聘。
11.4 它如何插入智慧路径
人类仍然会进行头脑风暴和讨论。原型和图表仍然存在。多代理团队加速 提案起草、ADR 脚手架、实施切片、Review Bot 分类和 GitOps 推广 ——而人类则对结果和风险进行判断。这就是工作站模型：为您的工作流程配置的代理工作站和 OpenClaw 软件包，而不是冒充团队的聊天窗口。
12. 端到端质量门
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. 入门清单
- 创造
docs/ideas/,docs/architecture/,docs/adr/ - 添加PR/MR模板+CODEOWNERS+分支保护
- 启用预提交 + CI 所需的检查
- 安装评论机器人；调整路径过滤器和严重性
- 写入 ADR-0001：“我们使用 GitOps 进行部署”
- 定义环境升级规则和回滚比赛日
- 如果扩展交付：带有 HITL 门的站立工作站多代理人员（规划者/构建者/审核者/操作者）
14. 反模式
- 巨大的“WIP，请批准”PR
- 仅在 Slack 中使用架构 - 从不在 ADR 中使用
- 原型合并为产品，无需测试
- 禁用评论机器人，因为它烦人
- 具有写访问权限且没有人工门的代理
- 对 GitOps 之外的产品进行修补，没有恢复计划
15. 结束
明智的开发人员将新项目视为一系列学习工件（笔记、图表、提案、ADR），然后通过由 Review Bot 监视并由 GitOps 推广的小型 MR/PR 进行交付。 Workstation 的多代理架构将这种智慧延伸到一个完整的开发团队中：专业代理、共享规范、重要的人工判断以及每条生存路径上的生产级门。这就是如何在业务快速发展的同时保持生产代码质量优化的原因。
发布者： 工作站.
