mancode 文档 / v0.3.18
mancode/文档

从日常训练到关键比赛

给你的编程 Agent
一套真正可执行的战术。

mancode 是一套本地优先的 Agent 工作流框架。它不替代 Claude Code、Cursor、Codex、Copilot 或 ZCode,而是给现有 Agent 增加项目上下文、任务强度、持久化产物、验收证据和评审闸门。

两个层次

日常使用时,你在 Agent 对话中调用 solo/manba/man。安装好的适配器会在背后调用 mancode workflow 维护持久记录。后面的 CLI 参考用于解释这份记录,并不是要求你手工再做一遍流程。

安装与初始化

需要 Node.js 20 或更高版本。你可以在现有项目或安全的空目录中初始化,然后选择一个或多个 Agent 适配器。Windows CMD、PowerShell 和 Git Bash 均受支持;Git 不是必需依赖,只会帮助 mancode 更准确地判断团队模式。

01安装

在本机全局安装一次 CLI。

02进入项目

进入希望 Agent 理解的项目目录。

03初始化

扫描项目事实并安装选定适配器。

$ npm install -g mancode
$ cd your-project
$ mancode init

指定平台或非交互初始化

--platform 接受逗号分隔的平台列表。自动化环境中应与 --yes 配合;只有当目录确实为空并且你明确想创建通用项目上下文时,才使用 --empty

$ mancode init --platform codex,cursor
$ mancode init --yes --platform codex --no-team
$ mancode init --empty --platform claude-code --lang zh-CN
选项适用场景实际效果
--force修复生成配置重新安装 mancode 管理的内容,同时保留已扫描的样式 token 和受控标记之外的用户内容。
--yesCI 或非交互终端接受安全默认值并跳过通用项目确认;建议同时给出 --platform
--platform LIST已经知道目标 Agent安装 claude-codecursorcodexcopilotzcode 中的一个或多个。
--empty目录有意保持为空无需先执行 git init 或创建 manifest,也能初始化通用项目。
--team / --no-team不采用自动判断结果强制开启或关闭团队共享上下文。
--style NAME已有明确的视觉偏好保存为默认样式偏好。
--lang en|zh-CN需要稳定的生成语言指定生成内容的语言。

验证安装结果

$ mancode status
$ mancode status --json

普通输出会列出项目、当前模式、团队状态、已安装平台,以及每个平台的 readynot ready 状态;脚本应使用 JSON,编码 Agent 可用 mancode status --brief --json 获取精简的 Continuity 公开视图。ready 表示适配器要求的生成文件已经存在,但不代表一个早已打开的 Agent 会话已经重新加载这些文件。

初始化后重载

安装后重启或重新加载编程 Agent,再用 solo 完成一个小任务。如果平台仍显示 not ready,执行 mancode install <platform> --force 修复。

文件与隐私

mancode 本地运行,只扫描当前项目,不发送遥测。它不会擅自改写项目的 .gitignore,因此哪些生成上下文应该进入版本控制,需要由你的团队明确决定。

路径包含什么提交前怎么处理
.mancode/schema.json
.mancode/shared/
.mancode/local/
Continuity 权威、项目策略、会话、工作流元数据和本地运行时记录。只有显式使用 --legacy 初始化后才会出现旧 state.json共享前检查工作流证据和本地记录;原始宿主 session key 不会持久化。
.mancode/shared/context/project.json
.mancode/local/cache/style-tokens.json
识别出的技术栈、验证命令和本地 UI token。检查是否带有内部项目信息,再权衡复现能力与暴露范围。
.mancode/local/workflows/
.mancode/shared/workflows/
需求、计划、评审和验证台账、报告、checkpoint 与总结。重点检查。证据和报告可能含敏感数据;shared workflow 必须通过 Continuity 隐私边界。
.mancode/shared/context/decisions/
.mancode/shared/team/
已确认决策与持久化协调权威。只提交有意写给团队的内容。
.claude/.cursor/.agents/.github/AGENTS.md平台 instructions、命令或 prompt、skills、hooks 与受控区块。团队确实把该适配器作为开发流程的一部分时再共享;mancode 管理标记之外的内容仍归用户所有。
安全边界

mancode manps 默认只扫描和报告,修复必须显式进入 remediation 路径。安装 mancode 也不会赋予 Agent 发布、删除或重写无关工作的权限;不可逆操作仍需人工确认。

跨会话继续工作

mancode 把目标、需求、计划、检查结果和交接信息保存在稳定的 TaskRef 下。新聊天窗口或受支持的 CLI 可以恢复同一项任务,再按当前目的读取精简的 Context Pack。

会带过去什么

这是任务上下文的续接,不是原始聊天记录的复制。不同客户端的 session 仍然隔离;新 session 必须使用自己的 client 身份,并显式恢复已有 TaskRef。

$ mancode status --brief --json
$ mancode context session new --client claude-code
$ mancode context resume <namespace:ULID> --session <id> --client claude-code
$ mancode context show --purpose orient --session <id> --client claude-code

生成的 /man/manba/manteam 入口使用同一套记录。CLI 形式适合排查、自动化或手工恢复。

选择最小够用的模式

任务长短不是唯一标准。应根据错误决策的代价,选择能够留下足够证据和评审、同时又不过度增加流程负担的最轻模式。

日常改动

solo

适合小功能、重构或 UI 微调。加载项目上下文,做最窄的有效验证,再进行一次受限 diff 自检,不引入独立评审循环。

Bug 或行为不确定

/manba

先复现,再定位根因,验证真实用户路径,并提供回归证据。

高风险决策

/man

冻结需求和版本化计划,然后由用户选择交给 solo 实施,或继续受治理的实现、验证与评审。

团队或维护

/manteam · /manps

增加共享记忆和交接记录,或者在维护前执行确定性的项目健康扫描。

判断原则

不要因为任务很长就默认使用 /man。当错误选择代价高、难以回滚,或事后很难审查时,再升级到它。

调用模式

模式名称是通用的,但调用方式取决于平台的扩展机制。下面这些内容应输入 Agent 对话框,而不是操作系统终端。/mansolo$mansolo 会显式回到默认 solo 模式。

模式最适合行为
solo日常开发项目上下文、轻量规则、相关验证和一次受限 diff 自检。
manba诊断问题复现优先的调试,明确根因,验证用户路径并留下回归证据。
man需求与治理式交付调研、澄清、版本化计划闸门、验收验证和风险驱动评审。
manteam共享项目团队记忆、决策、协作和便于交接的总结。
manps项目维护确定性扫描依赖、安全、死代码和配置问题。

Claude Code / Cursor

Commands

在对话中使用生成的斜杠命令。

/manba
/man
/manteam
/manps
/mansolo

Codex

Skills

在 App、CLI 或 IDE 中显式提及 skill。

$manba
$man
$manteam
$manps
$mansolo

GitHub Copilot

Prompts

在支持仓库 prompt 文件的客户端中,按模式名选择或调用生成的 prompt。

man.prompt.md
manba.prompt.md
manteam.prompt.md
manps.prompt.md
mansolo.prompt.md

ZCode

预览

适配器会安装项目 skills,但能否发现和如何调用取决于当前 ZCode 版本,请结合 mancode status 实测。

$man
$manba
$manteam

CLI 参考

CLI 负责安装适配器和强制执行持久化工作流状态。读取状态的命令应在已初始化项目中运行;非法状态转换会安全失败,不会静默篡改元数据。

mancode init

初始化

创建 .mancode/,识别项目,在适用时扫描样式 token,并安装平台适配器。

  • 选项:--force--yes--team--no-team--style <name>--platform <list>--empty--lang <locale>

mancode install [platform]

适配器

初始化后安装或修复一个平台。省略平台名时进入交互选择。

  • --force 重新生成受控内容。
  • --minimal 只安装 solo 的必要内容。

mancode status [--json] [--brief]

检查

报告项目事实、当前模式和工作流、平台就绪状态,以及适用时的 Claude hook 注册情况。组合使用 --brief --json 可获得精简的 Continuity 运行时视图。

mancode list-platforms

发现

列出当前 CLI 支持的平台,并标出项目中已经配置的平台。

mancode workflow <subcommand>

治理

创建和校验 Continuity 需求、计划、验证证据、评审、修复与完成状态。

  • 使用 listshow <namespace:ULID> [--json] 检查。
  • 使用 context compact --dry-run 检查可回收的运行时记录;Continuity workflow authority 不会被 workflow clean 删除。

mancode manps [area]

扫描

alldepssecuritydead-codeconfig 执行确定性健康扫描。

  • --json 输出机器可读结果。
  • --remediate 显式进入修复路径;默认只扫描。

mancode refresh-project

重扫项目

在加入 Git、manifest、框架或验证命令后刷新项目事实,并更新已安装的静态适配器。

mancode refresh-style

设计上下文

刷新项目画像和设计 token,之后可用 --force 重装需要更新的静态适配器。

mancode uninstall [platform]

移除

移除一个 Continuity 适配器。Continuity 会保护权威数据不被批量删除;用 context compact --dry-run 检查保留候选。--all 只适用于 legacy 项目。

mancode version

版本

输出已安装 CLI 版本,便于升级检查和提交问题。

深入研究 /man 工作流

/man 是一个渐进式九步协议:先让决策变得可检查,再由用户选择轻量交接、仅保留计划,或继续治理式执行。每个闸门都由 Continuity 的 .mancode/<namespace>/workflows/<ULID>/ 文件支撑。

谁来运行这些命令?

安装后的 Continuity mode entry 会创建任务并读取 Context Pack。下面展示的是供研究、排错或集成使用的机器契约。Continuity 使用显式 namespace:ULID TaskRef,不依赖旧的活动指针。

九个步骤与闸门

步骤Agent 工作持久化闸门
1 · Scout检查项目画像、现有实现、依赖、风险和未知项。写入 scout-report.md
2 · Clarify解决所有会改变决策的未知项,并区分阻塞项、可推荐项和可安全默认项。完成结构化需求台账;blockingUnknowns 必须为空。
3 · Plan写清范围、选择及理由、复用、排除项、行为、风险、回滚和真实验证。写入 plan.md;首版为 v1,修订时递增 planVersion
4 · Plan gate复述计划,让用户选择交给 solo、治理式执行、只保留计划或继续修订。没有明确选择之前,不允许进入实现。
5 · Implement只实现已确认计划所需的最小改动。保持范围;出现会改变决策的新事实时回到澄清或计划修订。
6 · Verify执行识别出的 build、lint、typecheck、test、smoke 和每一条必需验收标准。每个必需验收 ID 都有当前通过证据;手工检查必须获得用户显式确认。
7 · 质量评审只检查变更 diff 和直接影响,最多记录三个有证据的新问题。先写报告和稳定 blocker ID,再进入修复。
8 · 安全/边界评审只有 full review 执行:检查安全、权限、恢复、资源与边界;targeted review 把此域标为不适用。所需评审域全部完成,同一根因不得重复计数。
9 · 修复与完成在一轮 remediation 中解决 blocker;发生改动后重新验证并写总结。blocker 清零、验证仍然有效、存在 summary.md,才能设为 completed

结构化需求台账

需求台账用于防止一份看似完整的计划掩盖未解决假设。它必须包含目标、非空确认范围、七个覆盖维度和至少一条必需验收标准;技术栈适用时,technicalDecisions 不能为空。finalize 会生成规范化的 requirements.jsonrequirements.md

{
  "version": 1,
  "goal": "重构认证模块,同时保持登录行为不变",
  "confirmedScope": ["把 token 校验提取到现有 auth service"],
  "excludedScope": ["更换身份提供商", "重做登录界面"],
  "technicalDecisions": ["保留现有 TypeScript 与 session 技术栈"],
  "defaults": ["保持当前超时时间"],
  "blockingUnknowns": [],
  "coverage": [
    { "dimension": "platform", "status": "confirmed", "rationale": "Node 服务" },
    { "dimension": "core_scope", "status": "confirmed", "rationale": "仅重构" },
    { "dimension": "technical_stack", "status": "confirmed", "rationale": "沿用现有技术栈" },
    { "dimension": "data_and_persistence", "status": "not_applicable", "rationale": "无数据结构变更" },
    { "dimension": "performance", "status": "defaulted", "rationale": "不得低于现有基线" },
    { "dimension": "compatibility", "status": "confirmed", "rationale": "外部行为保持不变" },
    { "dimension": "security", "status": "confirmed", "rationale": "token 校验继续 fail-closed" }
  ],
  "acceptanceCriteria": [
    {
      "id": "AC-LOGIN",
      "description": "有效和过期 token 保持当前行为",
      "required": true,
      "method": "automated"
    }
  ]
}
$ mancode workflow requirements <local:ULID> finalize --file requirements-input.json --expected-revision <revision> --session <session-id>

成功结果会显示 ready。如果结果是 needs_clarification,必须停止推进,先解决 blockingUnknowns,重新生成输入后再次 finalize。

Step 4 的三种决策

交给 solo

实施

计划已经稳定,但实现风险属于日常范围。

$ mancode workflow handoff <local:ULID> --to solo --expected-revision <revision> --session <session-id>
# solo 实现并验证后
$ mancode workflow handoff <local:ULID> --complete --expected-revision <revision> --session <session-id>

治理式执行

继续

实现、证据和独立评审都需要保留在九步记录内。

$ mancode workflow plan <local:ULID> confirm --plan-decision governed_execution --expected-revision <revision> --session <session-id>

只保留计划

停止

用户需要的交付物是计划,而不是代码。

$ mancode workflow plan <local:ULID> confirm --plan-decision plan_only --expected-revision <revision> --session <session-id>

三种选择都要求活动中的 man 工作流、已确认需求和 plan.md。使用 workflow plan ... revise 修订计划;每次成功写入都会返回下一个命令需要的 revision。

一条合法的 Continuity 顺序

Continuity 使用显式 TaskRef 和 expected revision。所有持久化变更都由 CLI 完成;不要手工编辑 metadata,也不要使用 legacy --step 协议。

# 创建 actor 和显式 session
$ mancode team identity create --name "Your name"
$ mancode context session new --client codex --json

# 创建、发现并检查任务
$ mancode workflow create man "refactor auth module" --session <session-id> --json
$ mancode workflow list --json
$ mancode workflow show <local:ULID> --json

# 需求和计划闸门(每次使用上一个命令返回的 revision)
$ mancode workflow requirements <local:ULID> finalize --file requirements-input.json --expected-revision <revision> --session <session-id>
$ mancode workflow plan <local:ULID> revise --file plan.md --expected-revision <revision> --session <session-id>
$ mancode workflow plan <local:ULID> confirm --plan-decision governed_execution --expected-revision <revision> --session <session-id>

# 记录规范化评审和验证台账
$ mancode workflow review <local:ULID> apply --file review-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow verify <local:ULID> apply --file verification-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow complete <local:ULID> --expected-revision <revision> --session <session-id>

自动验证、手工确认与修复后重验

场景必须记录闸门行为
自动验证规范化 verification ledger 记录验收项、命令、退出码、证据摘要与结果。workflow verify ... apply 会拒绝不符合 Continuity schema 或 revision 的台账。
手工验证台账记录自动化不能判断的原因;只有用户明确确认后才能改为 passed。必需人工证据未完成时,completion 持续阻塞。
评审发现规范化 review ledger 保存稳定 blocker ID 及其 remediation 状态。应用 review ledger 会使旧验证失效;评审后、完成前必须 apply 当前验证。
用户跳过评审review ledger 记录用户显式决定和残余风险。仍然需要有效 summary 和其余全部门禁。
# remediation 后更新规范化台账
$ mancode workflow review <local:ULID> apply --file review-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow verify <local:ULID> apply --file verification-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow complete <local:ULID> --expected-revision <revision> --session <session-id>

workflow 子命令速查

命令用途关键选项
create创建 manmanbamanteam 记录。--parent <TaskRef> 关联诊断子任务;--json 输出 TaskRef。
requirements完成结构化需求台账。finalize --file --expected-revision --session
plan修订计划或确认执行决策。revise --fileconfirm --plan-decision;两者都需要 revision 和 session。
update改变生命周期状态或阻塞原因。--status --expected-revision --session;治理字段使用专用命令。
handoff把已确认的本地计划交给 solo,随后关闭。--to solo--complete,并传 revision 与 session。
verify / review应用规范化 Continuity 台账。apply --file --expected-revision --session
list / show / clean列出或检查 Continuity TaskRef;clean 不是删除 Continuity 权威数据的命令。show <namespace:ULID> --json;保留清理使用 context compact --dry-run

平台与适配器

mancode 按每个平台真实拥有的扩展点进行适配。标为预览的平台可以安装,但运行时能否发现或调用,仍受该平台当前版本能力影响。

平台安装内容使用说明
Claude Code.claude/ 下的 hooks、skills、subagents 和 commands。完整适配;安装后重启,让 session 与 prompt hooks 重新加载。
Cursor.cursor/rules/*.mdc.cursor/commands/*.mdrules 提供持久上下文;使用生成的 slash commands 显式进入模式。
CodexAGENTS.md.agents/skills/在 App、CLI、IDE 中用 $man* 显式提及 skill。
GitHub Copilot.github/copilot-instructions.md.github/prompts/*.prompt.md包含持久 instructions 与仓库 prompt 文件;不同客户端的 prompt 文件支持度可能不同。
ZCode(预览)AGENTS.md.agents/skills/ 中的项目 skills。请在已安装的 ZCode 版本中验证 skill 发现和调用。

刷新项目上下文

加入 Git、manifest、框架或验证命令后使用 refresh-project。设计系统迁移、UI 大改,或原本没有 UI 的项目新增界面时使用 refresh-style

$ mancode refresh-project
$ mancode refresh-style
$ mancode install cursor --force
  • refresh-project 更新项目事实和已安装的静态适配器。
  • Claude Code 通过 hooks 读取刷新后的上下文。
  • Cursor、Codex、Copilot 和 ZCode 使用静态文件;只有需要修复或重新生成时,才用 --force 重装对应适配器。
  • 只有 UI 项目会生成设计 token 相关指导。

安全卸载

卸载单个平台会保留用户自己编写的 rules、instructions、无关的 Claude settings 和 Continuity 工作流权威数据。使用 context compact --dry-run 检查可清理的运行时保留记录。

移除一个适配器

$ mancode uninstall cursor --force

重装一个适配器

$ mancode uninstall claude-code --force
$ mancode install claude-code

移除 CLI

$ npm uninstall -g mancode

故障排查

mancode init 拒绝当前目录

安全的空目录支持交互初始化,也可以显式使用 --empty。非空目录仍需存在可识别的项目标记或 Git 元数据,防止 mancode 意外初始化任意文件夹。

Agent 看不到刚安装的模式

重载或重启 Agent,让它重新读取仓库 instructions。执行 mancode status;如果平台未 ready,运行 mancode install <platform> --force。ZCode 和 Copilot 还需要确认当前客户端版本支持仓库 skills 或 prompt files。

Claude Code hooks 没有触发

初始化后重启 Claude Code,再用 mancode status 检查两个 hook 文件和 .claude/settings.json 注册状态。可执行 mancode install claude-code --force 修复。hooks 使用 Node.js,不依赖 Bash 或 jq。

Cursor rules 没有触发

确认 .cursor/rules/mancode-*.mdc.cursor/commands/*.md 都存在。核心上下文与 solo rules 持续生效;高强度规则按描述触发,因此应显式调用生成的模式命令。

workflow 命令被拒绝

把拒绝当作流程闸门,而不是元数据损坏。先用 mancode workflow list --json 找到 TaskRef,再用 mancode workflow show <namespace:ULID> --json 检查元数据、revision、aggregate 和 blocker。不要手工编辑 Continuity metadata。

项目事实已经过期

添加 Git、manifest、依赖或验证脚本后执行 mancode refresh-project;UI token 改变时执行 refresh-style。只有静态适配器的生成文件需要更新时,才重新安装对应平台。

没有找到匹配的文档章节。