Mancode

mancode

AI 编码代理工作流调度框架与本地优先 Continuity CLI，内置隐私保护与数据脱敏。默认 Solo + 五种治理模式： 训练到季后赛。别让你的 AI 过度设计一切，像个 man 一样肘开冗余，干净得分。

为 Claude Code、Cursor、ChatGPT 桌面端中的 Codex、Codex CLI、GitHub Copilot、 ZCode、Kimi Code、Qoder 和 DeepSeek Harness 提供结构化任务规划、跨会话上下文、 证据化代码审查和团队协作能力。

English · 官网 · 安装方法 · 使用方法 · 隐私与脱敏

---

目录

• mancode 是什么？
• 为什么使用 mancode？
• 安装方法
• 使用方法
• 跨会话继续工作
• 团队协作
• 工作原理
• CLI 参考
• 隐私和安全
• 故障排查
• 常见问题
• 仍在推进

mancode 是什么？

mancode 是一个 AI 编码代理工作流调度工具。它给 agent 不同强度的工作模式： 日常任务用轻量 solo，关键任务用季后赛级别的 /man，复杂任务让教练组 subagents 负责调研、计划、实现和审查。

mancode Continuity（跨会话与团队协作运行时 负责把任务、决策和验证证据安全地 带到后续对话，并协调多人或多 Agent 的任务权威。

隐私保护与数据脱敏让你在分享日志、配置片段或客户资料前先做本地检查，生成脱敏副本； 也可分别开启共享内容门禁，减少敏感上下文暴露。

mancode 会安装三类能力：

1. 工作流权威数据：管理显式 session、TaskRef、Context Pack、workflow 和团队协调。
2. Skills / modes：提供 solo、/manba、/man、/manteam、/manps、 /mansolo 工作流模式。
3. 平台 bootstrap：把原入口接到 mancode；只有 --legacy 才安装旧 hooks。

每个受支持平台继续使用原来的 man* 入口，并通过静态 bootstrap 接入统一的 Context Pack 与 workflow authority。当 AI 编码代理写太多代码、忽略已有 UI 系统、 跳过计划，或者关键改动需要稳定工程流程时，mancode 可以作为一层本地工作流约束。

mancode 不是 Claude Code、Cursor、Codex 或 Copilot 的替代品。它是在现有 agent 上加的一层工作流：提供上下文、模式切换和审查纪律。

为什么使用 mancode？

• 减少 AI 过度设计：先复用已有代码、标准库、已安装依赖和一行修复，再考虑新增抽象。
• 分享前先保护敏感数据：在本机识别凭据和个人信息、生成脱敏副本；按需拦截敏感共享写入，或在支持的模型请求字段发往上游前替换原值。
• 在存在 UI 时匹配现有设计系统：检查项目 UI 依赖、Tailwind 配置、CSS 变量和已有组件，让 agent 复用现有颜色、字体和交互模式。
• 先把需求和计划对齐：/man 会调研项目、引导澄清会改变方案的需求、推荐可行选项并生成可确认的持久计划；计划完成后不会自动进入完整实施。
• 自由选择执行方式：计划确认后，可只保留计划、交给单个 Solo 会话实施，或继续完整 /man；受管 Solo 交接仍继承原计划、范围、审查和验收门禁。
• 保留工作流产物：调研、计划、审查报告和总结会保存到 .mancode/<namespace>/workflows/<ULID>/。
• 文档绑定的模块交付：把需求、计划、实现范围、验收标准、验证证据、review 和完成门禁绑定到同一个 workflow。
• 可恢复的交付与重构：支持 delivery record、checkpoint、reframe 和 operation recovery，避免中断后把半完成状态当成最终结果。
• 支持团队上下文：/manteam 通过 .mancode/shared/ 的类型化实体共享已确认信息。
• 维护项目术语和决策：通过用户确认的 glossary、shared decisions 和 TaskRef 减少跨会话、多代理协作中的语义漂移。
• 扫描项目健康度：mancode manps 检测陈旧 TODO、未使用依赖、风险依赖、混用图标系统和硬编码设计值。

前后对比

没有 mancode 时，像“添加退出登录按钮”这样的请求，AI 可能会新建组件、新建样式文件、 新增颜色变量。

使用 mancode 后，agent 会看到你项目里已有的 Button 组件和设计 token：

<Button variant="default" onClick={handleLogout}>
  退出登录
</Button>

默认工作流会在写代码前推动 agent 思考六个问题：

1. 这个改动解决什么问题？
2. 能否复用已有实现？
3. 最小可行改动是什么？
4. 能否不拆新系统？
5. 非平凡逻辑怎样做最小运行验证？
6. 有什么没把握的（先自查，仍不确定再问用户）？

适合什么项目？

• 正在使用 AI 编码代理的后端、Web、移动端、桌面端、CLI、库、数据或混合项目
• 希望在原 man* 命令中使用 Context Pack、skills 和显式治理的用户
• 希望 AI 代理复用已有组件和代码模式的团队
• 需要可重复 AI 辅助代码审查流程的项目
• 需要分享含客户资料、凭据或本机路径的日志、文档和配置片段，并希望先生成脱敏副本的开发者
• 希望为团队共享上下文设置敏感内容门禁的团队
• 已有 UI 组件、主题、CSS 变量或设计约定的界面项目
• 希望保留本地团队记忆、使用不发送遥测的 CLI 的团队

模型自主性与工程标准

常驻指引保留项目事实和必要边界，专业 Skill 按需提供方法；工程标准由任务原有的 requirements、plan、review、verification 和完成门禁维持。

• 普通 solo 不要求身份、session、TaskRef 或正式计划；模型选择实施方法，运行与风险相称的验证并检查实际 diff。只有需要时才增加 reviewer。
• /man 保留需求澄清、批准计划、范围、验证、审查和提交要求。已有授权仍适用时继续执行，不因关键词重复审批；新的实质决定或越界影响仍需确认。
• Man → Solo 只改变执行者，不降低交付标准。证据缺失、失败或过期时不能完成，普通 Solo 的豁免不适用于交接任务。
• finding 必须有具体证据和用户影响。修复与复查遵循任务原 policy；有新问题时补查，不为固定轮数重复审查，也不能因做过一次 review 就忽略新缺陷。
• reviewer 进程成功退出不等于 review ledger 已通过；验证命令返回 0 也不等于验收已经满足，最终状态以结构化 ledger 和 completion gate 为准。
• 交付标题、summary、commit、PR 和 handoff 应基于已接受目标、权威基线、实际读回状态和本任务 diff；无法读回的外部状态必须标记为未验证。

模型可以灵活选择工具与实现步骤，但不能自行改写已批准的目标和验收标准。

v0.6.10 更新