先下判断：你的问题不是“不会用”，而是“还在用聊天模式管理一个交付系统”

你这份报告暴露出一个很清晰的画像：你已经是 Claude Code 重度用户。1,560 条消息、75 个主要会话、233 个文件、98 次提交，覆盖 E2E、CLI 配置、代理网络、认证、全栈开发、部署运维等复杂任务。你不是浅尝辄止，而是在把 Claude Code 当真实工程执行者用。报告里也提到，你常用“brainstorm → design spec → implementation plan → execute”的节奏，并且在 SSO、文档空间分配、E2E harness 等任务上确实产出了完整交付。

但你的痛苦点也很明显：你现在的模式是 “我发一个目标 → Claude 开干 → 我盯着 → 它偏了我纠正 → 它再开干 → 我再验”。这不是任务指派，这是现场监工。

你的目标是：

指派任务后，我可以离开，回来只做验收。

那你需要的不是更聪明的单次提示词，而是一个 “交付操作系统”：任务包、预检、执行边界、自动验证、独立审查、最终验收报告。

---

一、整体分析：你现在强在哪里，卡在哪里

1. 你强在“复杂任务拆解”和“快速纠偏”

报告里最正面的部分是：你能把 Claude Code 推进到真实复杂工程里，而不是只让它写小函数。你让它处理多仓库、认证、代理、E2E、迁移、部署、配置工具，这说明你已经把 AI 当成工程合作者，而不是问答机器人。

你还有一个很强的能力：发现方向错了会立刻打断。比如报告里提到你会把 Claude 从 Playwright 拉回 agent-browser，把错误 provider 纠正成正确测试路径，在 bash 循环里直接问“当前问题是什么”。这是高级用户的表现。很多人失败不是因为模型差，而是因为看着模型一路错到底。

但这个能力现在也变成了你的负担：你太擅长救火，所以 Claude 的工作流越来越依赖你救火。

---

2. 你卡在“验收标准不够机器化”

报告里反复出现的问题不是 Claude 不会写代码，而是：

• 猜 CLI 命令，不先验证；
• 错用工具，比如该用 agent-browser 却用 Playwright/curl；
• 环境问题拖垮任务，比如 proxy、port、venv、credits；
• 交付物受众理解错，比如测试分类文档写成内部说明，而不是上游输入契约；
• 没真的验证就声称完成。

这些问题的共同点是：你脑子里知道“什么叫做好”，但 Claude 没有被强制按这个标准自检。

官方最佳实践里也明确强调，给 Claude 明确的测试、截图、期望输出等验证方式，是最高杠杆的做法；否则它可能产出“看起来对、实际不对”的结果，你就会变成唯一反馈环。

这正是你痛苦循环的根源。

---

3. 你现在的使用强度很高，但“会话污染”也很重

你的报告里多任务会话很多，Bash 使用量极高，错误也不少：Bash 3,857 次、Command Failed 332 次、wrong approach 18 次、misunderstood request 12 次、pyright venv misconfiguration 8 次、port conflict 6 次。

这说明 Claude 很多时候是在“现场探索”，而不是按一个稳定流程交付。探索没错，但探索产生大量上下文、失败命令、错误假设，最后会拖累模型判断。

Claude Code 官方文档也提醒：上下文窗口会很快被对话、文件内容、命令输出填满，长会话会降低表现；如果同一个问题已经纠正两次，最好清空上下文，用学到的信息重新开一个更具体的提示。

你现在有点像把“试错现场”直接当“生产流水线”。

---

二、你的主要思维误区

误区 1：把“目标”当成了“任务包”

你经常给的是高层目标，比如“切到 develop 并 pull”“做 E2E”“修这个登录问题”。这对探索型工作很高效，但对无人值守交付不够。

真正的任务包至少要包含：

• 目标是什么；
• 不做什么；
• 已知约束；
• 首选工具；
• 禁止路径；
• 验收标准；
• 必须运行的验证命令；
• 失败时怎么处理；
• 什么情况下可以打断你；
• 最终报告格式。

你现在很多时候只给了“做什么”，没给“怎么算做完”。所以 Claude 会用自己的标准宣布完成，你就不得不回来补刀。

---

误区 2：过度依赖实时纠偏

你的纠偏能力很强，但这会让你陷入一个陷阱：你默认自己会在场。

这适合 pair programming，不适合 delegation。

你要从：

我盯着你做，发现错了我纠正。

升级成：

我先定义边界、验收和升级规则。你自己跑，跑完给我证据。

这不是提示词风格问题，是角色变化。你现在像技术负责人坐在旁边看 junior 写代码；你想要的是外包团队交付 MR。

---

误区 3：把 Claude 的错误当成“态度问题”，而不是“系统问题”

比如它猜命令、不验证、乱选工具、提前宣布成功。你当然会烦，但更有效的思路是：这些不是一次性错误，而是 流程缺少闸门。

如果同一类错误出现两次，就不要继续靠口头提醒。应该固化成：

• CLAUDE.md 规则；
• Skill；
• Hook；
• 子代理；
• preflight 脚本；
• 验收 checklist。

Claude Code 文档也区分了这些机制：CLAUDE.md 更适合放每次都要知道的项目规则；如果是多步骤流程，应该做成 skill；hooks 则适合“每次必须发生、不能靠模型自觉”的动作，因为 hooks 是自动触发的确定性脚本。

一句话：不要骂模型记不住，要把你的偏好变成系统约束。

---

误区 4：把“自动化”理解成“让 Claude 更自由”

这是危险的。真正的自动化不是放羊，而是 更严格的边界 + 更少的人工点击。

你想无人值守，就必须同时做两件事：

1. 放开低风险操作；
2. 收紧高风险边界。

Claude Code 的 auto mode、权限 allowlist、sandbox 可以减少频繁确认，但它们的价值不是“让 Claude 想干啥干啥”，而是让 routine 操作自动过、风险操作被拦住。

你现在的痛点是“想少互动”，但如果没有边界，少互动会换来更大的返工。

---

误区 5：用一个 Claude 同时当产品、架构、开发、测试、审查

报告显示你让 Claude 做全栈、E2E、运维、配置、调试。它能做，但一个上下文里同时承担太多角色，会产生两个问题：

第一，写代码的 Claude 会天然相信自己刚写的东西。
第二，调试过程会污染上下文，让后续判断越来越带偏见。

更好的模式是 Writer / Reviewer / Verifier：

• Writer：实现；
• Reviewer：新上下文审查边界、风险、代码质量；
• Verifier：只跑验收，不参与实现。

官方文档也建议使用多个会话、worktree、agent teams 或 Writer/Reviewer 模式；新上下文做 code review 会减少“刚写完就自我相信”的偏差。

你要的高质量验收，不能只靠同一个 Claude 自说自话。

---

三、你的思维模式可以怎么提升

1. 从“互动式推进”升级为“契约式委托”

你现在的核心升级方向是：每次任务开始前，先写交付契约。

交付契约不需要很长，但必须明确：

任务目标：
完成 xxx 功能 / 修复 xxx 问题。

背景：
相关 repo、分支、已有约束、已知坑。

首选路径：
优先使用 xxx 工具 / xxx skill / xxx 测试方式。

禁止路径：
不要使用 Playwright；不要猜 CLI；不确定命令先 --help；不要绕过类型检查。

验收标准：
1. 功能 xxx 可用；
2. 后端测试 xxx 通过；
3. 前端测试 xxx 通过；
4. 类型检查 0 error；
5. UI 需截图对比；
6. 必须给出修改文件列表和验证证据。

自主规则：
除非遇到以下情况，不要问我：
- 需要生产密钥；
- 需要破坏性操作；
- 需求存在互相矛盾；
- 验证连续失败 2 次且无法判断原因。

最终输出：
只给我：完成摘要、修改文件、验证命令及结果、风险、待我验收点。

这就是从“聊天”变成“派单”。

---

2. 从“我来验收”升级为“Claude 先自证”

你要强制 Claude 交付证据，而不是交付描述。

不要接受：

已完成，看起来没问题。

要接受：

验收证据：
- pytest tests/api/test_login.py：通过
- pyright：0 errors
- npm run test：通过
- agent-browser E2E：登录、跳转、权限校验全部通过
- 截图路径：artifacts/login-success.png
- 修改文件：...
- 未覆盖风险：...

这点非常关键。你现在的痛苦是回来以后还要自己判断“它到底有没有做完”。以后你要让 Claude 自己把验收材料准备好，你只做抽查。

---

3. 从“事后纠错”升级为“事前预检”

报告里大量摩擦来自环境：credits、proxy、port、venv、sandbox、分支状态。

这些不应该在任务中途才发现。你需要一个固定 preflight：

开始任何超过 10 分钟的任务前，先执行 preflight：
1. 当前分支和 git status；
2. 依赖环境是否可用；
3. venv / node / pnpm / pyright 是否正确；
4. 关键端口是否占用；
5. http_proxy / https_proxy / ALL_PROXY 是否影响 localhost；
6. API credit / model profile 是否可用；
7. sandbox / browser / database 是否可连；
8. 输出 preflight 表格，不通过则先修环境。

这类动作适合做 Hook 或 Skill。Hooks 适合确定性动作，因为它会在指定生命周期自动运行，不靠 Claude “记得”。

---

4. 从“长会话累积”升级为“阶段性清场”

你应该强制区分三种会话：

• 探索会话：允许读很多文件、试错、问问题；
• 计划会话：沉淀 spec 和 task list；
• 执行会话：只按 spec 做，不再发散。

官方建议大功能可以先让 Claude 采访你、产出完整 spec，然后新开干净会话执行，这能让实现阶段上下文更聚焦。

你的新规则可以是：

探索结束后，写 SPEC.md 和 ACCEPTANCE.md。
然后 /clear 或新开会话，只把 SPEC.md、ACCEPTANCE.md、相关文件喂给执行会话。

不要让“探索垃圾”进入“执行现场”。

---

5. 从“一个 AI 干到底”升级为“多角色流水线”

你可以这样组织：

Agent 1：Planner
只负责读代码、问问题、写 spec，不改代码。

Agent 2：Implementer
只按 spec 实现，不重新解释需求。

Agent 3：Verifier
只跑测试、E2E、截图、类型检查，不写功能代码。

Agent 4：Reviewer
新上下文审查 diff，找边界 case、安全问题、架构偏差。

Subagents 的价值就在于隔离上下文、保留主会话干净，并能限制工具和专门化角色。

你现在缺的不是“更多 Claude 窗口”，而是“每个 Claude 的职责边界”。

---

四、你最该改的 5 个具体习惯

习惯 1：不要再直接说“帮我做 xxx”

改成：

先不要实现。请先读相关代码，输出：
1. 你理解的目标；
2. 涉及文件；
3. 关键风险；
4. 实施计划；
5. 验收标准；
6. 需要我确认的问题。

如果没有阻塞问题，再进入实现。

这会把错误挡在动手之前。

---

习惯 2：任何任务都要写“禁止路径”

你的报告里 wrong approach 很多。不要只说“用 agent-browser”，要说：

浏览器自动化必须优先使用 agent-browser。
禁止默认使用 Playwright、curl 或 hermes 替代。
如果 agent-browser 不可用，先报告原因，不要自行换工具。

AI 经常不是不知道你要什么，而是不知道什么不能做。

---

习惯 3：超过两次纠正，立刻重开

不要在同一上下文里反复骂它。你的新规则应该是：

如果同一问题我纠正你两次，停止继续尝试。
总结：
- 错误路径是什么；
- 已知事实是什么；
- 新的正确约束是什么。
然后我会 /clear，用这份总结重新开始。

这比在污染上下文里继续缠斗更快。Claude 官方也把“反复纠正导致上下文污染”列为常见失败模式。

---

习惯 4：不要让实现者自己做最终审查

同一个 Claude 可以跑测试，但不要让它独占最终质量判断。你可以要求：

实现完成后，启动一个独立 reviewer subagent。
Reviewer 不允许参考实现过程，只看 spec、acceptance、git diff。
输出：
- 是否满足需求；
- 有无遗漏；
- 有无安全/权限/数据一致性风险；
- 建议修改项；
- 是否建议我验收。

这会显著减少“它自己觉得自己完成了”的问题。

---

习惯 5：把重复纠正变成资产

你报告里已经有很多可固化规则：

• 不猜 CLI，先 --help；
• E2E 优先 agent-browser；
• localhost 请求前处理 proxy；
• UI/CSS/font 改动必须浏览器验证；
• pyright venv 要先确认；
• 端口冲突先检查；
• 不确定模型身份不要胡说。

这些不要每次手打。它们应该进入：

• ~/.claude/CLAUDE.md：个人全局偏好；
• 项目 CLAUDE.md：项目规范；
• .claude/skills/e2e-bootstrap/SKILL.md：E2E 固定流程；
• hooks：JSON 校验、preflight、测试触发；
• reviewer subagent：最终验收。

---

五、解决你“对话—等待—再对话”痛点的完整方案

你要建立一个 “无人值守交付模板”。

以后复杂任务直接这样发：

你现在进入“无人值守交付模式”。

目标：
[写清楚要完成的功能/修复/部署]

背景：
[repo、分支、相关模块、已知问题]

首选工具与约束：
- 浏览器/E2E 使用 agent-browser，不要默认 Playwright/curl。
- 不确定 CLI 命令时必须先运行 --help，不要猜。
- localhost/internal 请求前检查并处理 http_proxy/https_proxy/ALL_PROXY。
- 不允许跳过类型检查、测试、迁移验证。
- 不允许用临时 hack 掩盖根因。

执行流程：
1. 先做 preflight，检查分支、依赖、venv、端口、proxy、数据库、sandbox、API/model 可用性。
2. 输出简短计划。如果没有阻塞问题，直接执行，不要等我确认。
3. 实现过程中遇到普通失败，自行诊断并最多重试 2 轮。
4. 如果连续 2 轮失败，停止，输出根因假设和下一步建议。
5. 实现完成后，运行验收命令。
6. 启动独立 reviewer/verifier 检查 diff 和验收标准。
7. 修复 reviewer 提出的必须修问题。
8. 最后给我验收报告。

验收标准：
- [测试命令 1] 通过
- [测试命令 2] 通过
- [类型检查命令] 0 error
- [E2E 场景] 通过
- 如果是 UI，必须提供截图路径和差异说明
- 如果改数据库，必须说明 migration chain 和回滚方式
- 如果改权限/认证，必须列出安全边界

最终报告格式：
1. 完成了什么
2. 修改了哪些文件
3. 验证命令与结果
4. Reviewer 发现与处理
5. 剩余风险
6. 我需要重点验收的 3 个点

这段的关键不是措辞，而是它改变了责任结构：Claude 不再是“等你下一句话的聊天对象”，而是“拿着合同交付的人”。

---

六、你可以立刻搭的 3 个 Skill

1.

/preflight

用途：所有长任务前先跑。

内容：

# Preflight

Before any task expected to take more than 10 minutes:

1. Show current repo, branch, git status.
2. Check whether working tree is clean or explain dirty files.
3. Check Python venv / Node / package manager.
4. Check pyright / pytest / npm scripts availability.
5. Check occupied ports relevant to this app.
6. Check http_proxy, https_proxy, ALL_PROXY; warn if they affect localhost.
7. Check database/API/UI/sandbox availability if relevant.
8. Check current model/profile/credit availability if possible.
9. Output a table: item, status, evidence, fix if failed.

Do not start implementation until critical preflight failures are resolved.

---

2.

/delivery-mode

用途：把任务从聊天变成交付。

# Delivery Mode

Operate as an autonomous delivery agent.

Rules:
- First understand the task and write a short plan.
- Do not ask the user unless blocked by missing secrets, destructive operations, or contradictory requirements.
- Verify commands before using unfamiliar CLIs.
- Prefer root-cause fixes over symptom suppression.
- Keep a running task list.
- After implementation, run tests/typecheck/lint/E2E as applicable.
- Use an independent reviewer subagent to review the final diff.
- Final answer must include evidence, not claims.

---

3.

/acceptance-review

用途：专门验收，不参与实现。

# Acceptance Review

You are an independent reviewer.

Inputs:
- SPEC.md
- ACCEPTANCE.md
- git diff
- test output
- screenshots if UI

Do not trust the implementer's summary.
Check:
1. Requirement coverage
2. Edge cases
3. Security and permission risks
4. Data consistency
5. Migration safety
6. Test adequacy
7. Whether final evidence proves completion

Output:
- PASS / FAIL / PASS WITH RISKS
- Missing requirements
- Risk list
- Required fixes
- Suggested manual checks

这三个 Skill 比你继续优化提示词更有价值。

---

七、对你个人思维模式的更深一层建议

你现在像一个很强的“问题解决者”，但要升级成“系统设计者”。

问题解决者会想：

这次 Claude 又猜命令了，我提醒它。

系统设计者会想：

凡是不确定 CLI 的情况，必须先 --help；这个规则进入 CLAUDE.md 和 delivery skill。

问题解决者会想：

这次 proxy 又坑了我。

系统设计者会想：

proxy 是 preflight 必检项，不通过不得开始长任务。

问题解决者会想：

这次它又提前说完成。

系统设计者会想：

没有测试结果、截图、diff review 的完成声明一律无效。

问题解决者会想：

我怎么让它少问我？

系统设计者会想：

哪些问题它可以自己决定？哪些必须升级？升级条件写进任务契约。

你的下一阶段不是“更会提问”，而是 更会定义工作系统。

---

最后给你一个很直接的结论

你目前最大的思维误区是：想要“任务指派式结果”，却还在使用“对话纠偏式流程”。

要摆脱痛苦循环，不是靠一句神级 prompt，而是靠这套结构：

任务包 → preflight → plan → autonomous execution → self-verification → independent review → acceptance report

你只要先把 /preflight、/delivery-mode、/acceptance-review 这三个东西固化下来，你的体验会立刻变。不是因为 Claude 突然变聪明，而是因为你终于不再把自己放在唯一反馈环里。