和龙虾协作的实战要点

Posted on In
从「AI 用户」进化为 Harness Engineering 实践者——学会设计自己的规范和流程，把 AI 能力固定在工作流里。

系列目录

和龙虾协作的实战要点

前言：本篇想告诉你什么

做任何事情，人都会遇到几类经典的问题：

方向的问题 — 做到一半发现方向偏了，要么硬着头皮继续，要么推倒重来。白花了很多时间。

节奏的问题 — 需求一口气说完，等一个完整的结果，结果发现方向完全不对。沟通成本比没有规范的时候还高。

积累的问题 — 做完了没留记录，下次再做同样的事，又要重新想一遍。经验永远归零。

边界的问题 — 做到某个环节，发现自己没想过这一步要怎么处理，不同人、不同系统的做法完全不一样，全靠临场发挥。

这些不是 AI 时代才有的问题。它们是人做事本身就会遇到的问题。好的工作方法、好的流程设计，本质上都是在解决这四类问题。

那么，当人和 AI 协作的时候，这些问题怎么变化？

AI 不了解你的目标，你说不清楚，它就按自己的理解做。方向偏了，AI 比人走得还快。

你把需求一口气说完，AI 直接开干，做完发现不是你要的。返工成本比纯人工还高。

AI 每次新会话都是从零开始，不主动记住上次做了什么。你不建立上下文，每次都要从零解释。

AI 不知道你的项目结构、技术栈、安全要求。你不说，它就按默认方式处理，结果可能不是你想的。

这些问题，本质上还是那四类问题。只是 AI 能力强了、跑得快了，问题被放大、更难察觉。

所以答案不是「怎么更好地问 AI 问题」，而是怎么设计一套框架，让 AI 在这套框架里稳定地产出。这正是一些先进的 AI 工具在做的事：

Claude Code 有完整的项目制管理思路：

  • Plan Mode（规划模式）：切换到只读模式，先探索代码库、出方案，用户确认后再执行。强制你先想清楚再动手。
  • Agentic Loop（代理循环）：收集上下文 → 执行行动 → 验证结果，循环直到任务完成。你可以随时中断和引导。
  • Checkpoint（检查点）：每次编辑前自动快照，出了问题可以回退。不只是版本控制，而是实时的安全网。
  • CLAUDE.md + Auto Memory：用户写的持久化指令 + Claude 自动记录学习到的模式，跨会话积累上下文。
  • Permission Modes（权限模式）：不同安全级别的操作需要不同级别的确认，避免意外执行高风险命令。
  • 多层配置系统（settings.json）：项目目录下放 .claude/settings.json，可以配置权限规则、MCP 服务器、Hooks、Subagents 等。所有行为都可以通过配置文件改写，不只是全局设置。

我要求龙虾（OpenClaw）做双区识别：临时区随手问，项目区认真设计。不同的任务用不同的方式处理，不混在一起。

这些工具的做法，和我一直摸索的方向是一样的：给协作设计约束，让产出稳定可预期。

这套思路有个名字：Harness Engineering。「Harness」的本意是马具——把野马驯服，让它为你所用。用在 AI 上，意思是给 AI 一个框架，让它在你设定的方向上输出稳定的价值。

Engineer 不是使用者，是设计师。你要设计 AI 和你协作的方式。

本篇想告诉你的，就是人应该关注什么——不是 AI 能做什么，而是我应该设计什么。

后面分两个部分讲：第一部分从 AI 协作视角看需要设计什么，第二部分从人的视角看需要关注什么问题。框架是相通的，只是看问题的角度不同。

如果你看过前几篇，可能会想「双区」「三阶段」已经讲过了，怎么又在讲？这篇讲的是「为什么」——帮你把零散的做法串成一套可以迁移的思考方式。不只是照搬做法，而是知道底层逻辑。

一、Harness Engineering 的核心：本意与落地

Harness 的本意是「马具」——给野马套上笼头，让它听你指挥。

用在 AI 上，这个词有两层意思：

第一层：驯服。 AI 很强，但不听话。你不设计框架，它就按自己的理解来。你说「帮我看看」，它不知道你是要分析、改、还是测试。你说「做完就行」，它不知道「行」的标准是什么。野马不知道自己该往哪跑。你得先把它驯住，让它知道听谁的。

第二层：固化。 光驯服不够，驯完它还是可能乱跑。你要把驯的结果固定下来——用流程、用规范、用文档。下次它还是按你设计的方式走，而不是又要重新驯一遍。这就是为什么我们要设计 MEMORY.md、设计双区、设计三阶段——本质是把驯的结果固化下来。

所以 Harness Engineering 的核心是两件事：

  • 驯：给 AI 套上框架，让它知道什么该做什么不该做、做到什么程度算「行」
  • 固：把驯的成果写进文档，让它不只是一次性的体验，而是可复用的规范

顺着这个思路，你会发现后面要关注的四个维度，其实都在回答「怎么驯」和「怎么固」这两个问题：

  • 维度一：区分问题性质 — 驯的方法：不是所有事都用同一个方式处理，该随手问的就随手问，该认真设计的就认真设计
  • 维度二：设定执行节奏 — 驯的方法：不让 AI 闷头做完，而是边做边验证，方向偏了及时修正
  • 维度三：积累有效记忆 — 固的方法：把经验写进文档，下次不需要重新驯
  • 维度四：设计协作边界 — 固的方法：把禁区、标准、风险说清楚，AI 就不会越界

这四个维度不是凭空想出来的，是从「怎么驯」和「怎么固」这两个问题自然推导出来的。你不需要照搬任何人的具体做法，但你可以用这个框架来设计适合自己的规范。

二、人应该关注的四个维度

从人的视角看，具体要关注什么问题、怎么设计这些维度。

维度一：区分问题的性质

核心问题：这件事是一次性的，还是需要持续做的？

一开始我也没有这个概念。有一次让龙虾改一个配置文件，它直接改了、改完汇报了，结果不是我要的，改回去又花了双倍时间。沟通成本反而比没有规范的时候更高。

从那次开始，我意识到：没有设计的时候，龙虾会直接开干，做完发现不是你要的，返工。

后来我想清楚了：方向不偏的方法，是在动手之前先判断——这件事是一次性的还是需要持续做的。

一次性的问题不需要留痕迹。查个配置、写个正则表达式、临时处理一个问题——做完就结束，不需要记录，不需要设计流程，下次遇到同样情况再说。

但如果是持续做的项目，你需要设计流程：这件事以后还会发生吗？发生的频率高吗？涉及哪些文件、哪些人、哪些环节？

这个判断直接影响后续怎么做。如果判断错了，把临时区当项目区用，代码改完不留记录，下次找不到改哪了；如果把项目区当临时区用，本来应该走三阶段流程的，直接开干，做完发现方向不对，要从头来。

怎么练这个判断力：每次收到需求，先问自己「这件事三个月后还需要记得吗？」如果答案是「是」，就按项目区走；如果是「不是」，直接给结果就行。

在我们的规范里落地的点：

  • 「临时区」和「项目区」的划分，就是对应该问题的解法
  • 临时区随手问，不留痕迹；项目区走设计，不留死角

维度二：设定执行的节奏

核心问题：这件事做完，需要几步？

很多人犯的错误是：需求一口气说完，然后等一个完整的结果。结果发现方向偏了，要从头来。沟通成本比没有规范的时候还高。

正确的做法是设计验收节点：把一个大任务拆成几个阶段，每个阶段完成后验收一次再做下一步。这样方向偏了能及时修正，不会等到最后才发现全部白做。

具体来说，项目区任务走「规划→执行→沉淀」的顺序：

  • 规划阶段：先出方案，用户确认方向对了再动手
  • 执行阶段：做的时候分批验收，不要一次性全部完成
  • 沉淀阶段：做完之后记录变更，让这次做的经验留在文档里，下次能用

这套节奏的核心是：不要闷头做完，而是边做边验证。

这套「规划→执行→沉淀」的节奏，其实不是凭空想出来的。它和质量管理领域的 PDCA 循环（Plan-Do-Check-Act，戴明循环）高度吻合：

  • Plan（计划） → 对应「规划阶段」：先出方案，确认方向
  • Do（执行） → 对应「执行阶段」：按方案执行，边做边验收
  • Check（检查） → 对应「分批验收」：每个阶段完成后检查产出是否符合预期
  • Act（处理） → 对应「沉淀阶段」：把经验固化到文档里，下次复用

PDCA 强调的是「循环」——每次做完了要复盘，复盘的结果要写进规范，下次才不会再犯同样的错。这和我们设计 MEMORY.md 的思路完全一致。

还有一个和 AI 协作特别相关的方法论：OODA 循环（Observe-Orient-Decide-Act）。它原本是军事决策用的，但拿来理解 AI 协作也很贴切：

  • Observe（观察）：AI 收集上下文，了解当前状态
  • Orient（判断）：AI 根据指令和上下文，形成执行方案
  • Decide（决策）：你确认方案，或者调整指令
  • Act（行动）：AI 执行，你验证结果

OODA 循环的关键是「不要等 AI 闷头做完再验证」，而是持续观察、不断调整。Plan Mode 就是这个思路的产品化——先只读探索、出方案，确认了再动手。

举一个具体的表达方式：

不好的说法：

帮我看看这个代码有什么问题

好一点：

帮我看看这个代码，重点关注性能和内存，不要改动任何文件，只给分析

更好的说法：

帮我看看这个代码，重点关注性能和内存占用。如果有问题，用列表形式输出：具体行号、问题描述、修改建议。不要改动任何文件，不要生成新文件。

最后这个版本，产出完全可预期：列表格式、不动文件、不多不少只做分析。

在我们的规范里落地的点：

  • 「三阶段执行流程」：规划 → 执行 → 沉淀
  • 子任务机制：把耗时操作隔离到独立会话，主会话保持空闲

维度三：积累有效的记忆

核心问题：AI 这次产生的价值，怎么延续到下次？

有一段时间，每次对话结束龙虾都把当天做的事忘光了。新会话开始，又要重新解释项目背景、技术方案、历史决策。每次都在重复同一个初始化的工作。

这个坑逼着我去想：怎么让每次做的有价值的事情，能留下来？

龙虾有两层记忆系统：

  • 日常记忆：memory/YYYY-MM-DD.md，记录当天做的决策和变更，像是日记本
  • 长期记忆：MEMORY.md，提炼后的核心信息，每次新会话自动加载

还有一个 SOUL.md，控制 AI 的说话风格和行为准则，调整它可以改变 AI 响应你的方式。

积累记忆的核心原则是：不要依赖 AI 主动记住，而是你主动写进去。

具体做法：每次纠正 AI 一个理解偏差，顺手把这个点写进 MEMORY.md。比如它每次处理日期格式都不对，在 MEMORY.md 里加一条：

1
2
3
## 日期格式规范
- 所有日期格式：YYYY-MM-DD
- 时间格式：24小时制，GMT+8

这个动作的成本很低——写进去只需要一分钟。但它解决的是「同样的错不犯第二遍」，而且效果是持续积累的。

另一个重要的做法：新会话开始时主动给上下文。龙虾不会主动去读你的项目文件。你不主动提供背景，它就靠猜。所以每次开始一个新任务，先交代清楚：「我们继续上次的某个项目，现在是哪个阶段，上次确认的技术方案是……」

还有一个容易被忽略的：项目文档。每次项目有重大决策、技术选型、架构调整，都应该写进文档里。这些文档不只是给人看的，也是给龙虾看的。下次回到这个项目，龙虾可以通过读文档快速了解项目的背景和历史，而不是每次都要从零解释。

恢复上下文的高效方式：想让龙虾快速进入状态，可以直接说：

  • 「回顾一下这个项目当前的一个进度，有什么问题？」
  • 「帮我看看这个项目最近的变更记录」
  • 「给我讲讲这个项目的技术架构」

这些表达方式比「你还记得上次我们做了什么吗」更有效。龙虾会主动去读项目的 MEMORY.md、变更记录、技术文档，然后给你一个清晰的当前状态概览。

在我们的规范里落地的点：

  • MEMORY.md / SOUL.md 机制
  • daily news 的定时抓取和归档
  • 飞书知识库同步
  • 项目文档（技术方案、决策记录、变更日志）

维度四：设计协作的边界

核心问题：AI 不知道什么，你需要提前说？

你还需要知道** AI 能做到什么、不能做到什么**。不了解这个，你说出来的约束可能是无效的——你以为 AI 能自动遵守，但它根本做不到。

所以这一节分两部分：第一部分讲你要说什么（说禁区、说标准、说风险），第二部分讲 AI 的能力边界（它能做到什么、不能做什么）。

第一：几个最常见的边界设计

说禁区，不说方向。 「不要用递归」「不要改配置文件」「不要超过 100 行」——这些禁区如果不提前说，龙虾不知道。说出来成本几乎为零，但能避免很多返工。

说标准，不说结果。 「做完就行」和「做完要能跑通单元测试、commit message 符合规范、push 到远程」——这两者之间差了十倍的细节。标准越清楚，产出越接近预期。

说风险，不说默认值。 删除文件、执行有副作用的命令——它默认你会确认，但你不说明，它就当作你已经同意了。「用 trash 而不是 rm」「不要在生产环境执行没见过的命令」，这类安全约束要说在前面。

第二：AI 的能力边界

大模型的通用能力边界

大模型（LLM）有几个系统性的局限，理解它们能帮你更准确地设计约束：

1. 幻觉问题：会一本正经地说错话

大模型有时候会生成听起来很合理、但实际上是错误的信息。它不知道自己说的是错的，也不会主动说「我不确定」。

应对方式：涉及事实性信息要求 AI 给出信息来源；不要让 AI 猜测项目里不存在的方法或文件；重要技术决策自己验证。

2. 上下文窗口限制：装不下太多内容

每次对话能处理的信息量有限。太长的对话会导致早期内容被遗忘，产出质量下降。

应对方式：长项目要给关键上下文，不要假设 AI 能记住所有历史；MEMORY.md 要定期精简；超长任务拆解。

3. 数学和计算：容易算错

大模型做复杂数学运算的可靠性不高，尤其是大数字、长时间序列计算。

应对方式：让 AI 写计算逻辑，但自己验证结果；涉及量化分析用外部工具。

4. 工具调用不一定可靠：会调用失败或用错工具

大模型使用工具的能力在提升，但仍然会失败：调用了错误的工具、参数传错了，没有处理错误返回值。

应对方式：工具执行后检查结果；关键操作要用户确认；失败重试给明确指令。

5. 对自己的「不知道」不敏感：会过度自信

大模型通常不会主动说「这个我不确定」，而是倾向于给出一个答案。

应对方式：重要问题换一种方式问交叉验证；对 AI 给的代码配置不要直接用，先理解再执行。

龙虾（OpenClaw）特有的能力边界

除了大模型的通用边界，龙虾作为具体工具还有几个限制：

上下文窗口由模型决定。 MiniMax M2.7 的上下文窗口大约是 100K tokens，超过这个量级早期内容会被遗忘或降权。长对话要定期精简 MEMORY.md；超长任务拆成子任务。

文件系统访问受限。 龙虾只能访问 workspace 目录下的文件，不能随意访问系统其他位置。你的项目文件必须在 workspace 里，龙虾才能找到。

危险操作需要用户确认。 删除文件（rm）、执行系统级命令、发布到生产环境——这些操作龙虾不会擅自执行，必须用户确认。这既保护了你的系统，也意味着你不能完全放手让龙虾自动运行。

子任务并发数量有限。 龙虾默认最多同时运行 4 个子任务。设计任务时要考虑这一点。

工具配置影响可用性。 龙虾的 tools.profile 设为 coding，某些工具可能不可用。需要用特定工具要调整配置。

判断：什么适合交给龙虾做

适合做的：

  • 需要大量上下文理解的工作（分析代码库、出方案）
  • 需要跨文件检索和修改的工作
  • 需要持续多轮对话迭代的工作
  • 文档撰写、代码生成、测试用例编写

不太适合做的：

  • 需要实时数据的任务（龙虾的 web_fetch 能力有限）
  • 需要精确数值计算的任务（用外部工具）
  • 需要长时间连续运行的任务（用子任务机制）
  • 涉及敏感操作的最终执行（人工复核）

第三：能力边界之外还有什么

AI 的能力边界不是固定的，可以往外扩展。

MCP（Model Context Protocol）调用远程接口

龙虾本身不能访问外部服务，但你可以通过 MCP 协议让它调用远程 API。比如：

  • 调用飞书接口发送消息
  • 调用 GitHub API 操作仓库
  • 调用数据库查询数据
  • 调用搜索 API 获取实时信息

这些远程能力，相当于给龙虾装上了「外挂」——它自己做不到的事，可以委托外部服务完成。所以当你设计协作边界时，不要只想着「龙虾能做什么」，还要想「通过 MCP 能扩展什么」。

Agent 内置的 Skill 和工具链

龙虾（OpenClaw）本身就内置了 Harness 的一部分。

比如当你让龙虾「生成微信排版」，它会自动调用对应的 Skill 完成。你不需要告诉它怎么做，它自己知道用什么工具、走什么流程。

Skill 的内外结合机制

龙虾的内置意图识别机制，可以识别和加载自定义的 Skill。两者结合形成扩展：

  • 内置部分：意图识别（根据 SKILL.md 的 triggers 字段匹配）、工具执行（read/write/exec 等）
  • 自定义部分：通过项目级或工作区级的 SKILL.md 定义特定技能的工作流程

这种「内外结合」的机制，让龙虾既保持了核心能力的稳定性，又具备了灵活扩展的可能性。

基础设施和远程服务

除了 MCP 和内置工具，还有一类东西可以扩展能力边界：基础设施和远程服务。

比如：

  • CI/CD 系统：龙虾生成代码，但实际的测试和部署由 CI/CD 完成
  • 数据库：你问龙虾项目状态，它通过查询数据库给你答案
  • 知识库：龙虾通过检索知识库来获取项目相关的历史信息

这些东西不在龙虾本身的能力范围内，但通过集成可以成为协作的一部分。你在设计 Harness 的时候，要把「什么交给 AI 做，什么交给基础设施做」分清楚。

总结：边界的扩展思路

AI 的能力边界不是铁板一块，而是可以扩展的：

  • 龙虾内置：工具链、Skill、流程、安全机制
  • MCP 扩展：远程 API、第三方服务
  • 基础设施：CI/CD、数据库、知识库、大流程

设计 Harness 的思路：先看龙虾内置了什么，再看 MCP 能扩展什么，最后看哪些交给基础设施。

三、两个维度的对应关系

第一章讲的是 Harness Engineering 的核心——「驯」和「固」。第二章讲的是人应该关注的四个维度——区分问题性质、设定执行节奏、积累有效记忆、设计协作边界。

这两个部分是什么关系？

简单说：「驯」对应的是维度一和维度二，「固」对应的是维度三和维度四。

为什么这么分？

「驯」是把 AI 的行为约束住，让它不要乱来。维度一（区分问题性质）和维度二（设定执行节奏）做的就是这个——告诉你什么情况用什么方式处理、不闷头做完。约束的是 AI 的行为边界。

「固」是把协作的结果留下来，不是一次性的。维度三（积累有效记忆）和维度四（设计协作边界）做的就是这个——把你的经验写进文档、把禁区说清楚，下次不需要重新解释。固化的是协作的上下文。

这个对应关系在实际中怎么体现？

拿 ai-blog 项目为例：

「驯」的部分体现在：

  • 收到写文章的需求，先判断是临时问还是项目做（维度一）
  • 项目做的时候，先出大纲再动笔，不闷头写完再改（维度二）

「固」的部分体现在：

  • 每次修改后同步飞书、更新变更日志，下次打开还能接着走（维度三）
  • 告诉龙虾「不要改我还没审核的内容」「危险操作要先确认」，这些禁区说清楚（维度四）

这四个维度不是割裂的，是配合着用的：先用维度一判断走哪条路，再用维度二控制节奏，然后用维度三积累上下文，最后用维度四守住边界。

四、如何设计更友好的规范

四个维度是通用的，但具体怎么做，每个人不一样。这一节讲设计规范的方法论。

规范要有反馈机制

一个规范如果没有办法验证是否生效，就等于没有。

比如「变更后要记录日志」这个规范，怎么验证？可以在每次会话结束前问自己：「今天做的变更记录了吗？」如果没记，就是规范没有执行。

再比如「项目区要先出设计方案」，怎么验证？看每次做之前有没有设计文档，而不是做完之后再补。

能验证的规范才能执行，不能验证的规范只是愿望。

规范要能跟随项目进化

规范不是一锤子买卖，是需要迭代的。

刚开始的项目可以用最简单的版本：只要有变更就记录，不要追求格式、不要追求完整。随着项目变复杂，规范也要变复杂。

比如 ai-blog 这个项目一开始只有博客功能，规范很简单。后来加上了 CI/CD、加上了飞书同步、加上了系列文章管理，规范也跟着细化。

怎么判断规范需要调整：每隔一段时间问自己——有哪些需求反复说要改？有哪些反馈用了很多次还是达不到？这些信号说明要么是需求接口没设计好，要么是规范本身需要调整。

设计规范的核心原则

好的规范不是想出来的，是踩出来的。

每次出问题，记下来：是什么问题、当时怎么处理的、以后怎么避免。积累一段时间后，你会发现某些问题反复出现，这时候就找到了规范需要解决的核心痛点。

从这个角度说，Harness Engineering 不是一套现成的模板，而是一套从踩坑到总结的持续迭代方法。

五、这一套框架的底层逻辑

讲完具体做法，这一节从更高角度讲为什么要这样做。

一切的核心：把人的经验外化

人做事的经验丰富，但这些经验如果不写下来，就只存在于脑子里，下次遇到同样的情况，又要重新想一遍。AI 没有记忆，你每次都要从零解释。MEMORY.md 就是解决这个问题的：把你的经验从脑子里搬出来，写进文件，AI 每次新会话自动加载。

这不是 AI 时代的特殊做法。任何领域的高手都会做这件事——写笔记、画流程图、做复盘文档。本质是一样的：把一次性的经验，变成可以复用的资产。

积累得越多，AI 越懂你。配合越久，效率越高。

问题不变，解决问题的工具在变

人做事会遇到四类经典问题：方向、节奏、积累、边界。这四类问题在 AI 时代没有消失，只是表现形式变了。

比如「方向的问题」：以前是你自己理解偏了，现在是 AI 理解偏了。「节奏的问题」以前是你自己没规划好，现在是你和 AI 都没规划好。「积累的问题」以前是经验记不住，现在是经验 AI 也不记得。「边界的问题」以前是你不清楚协作边界，现在是你和 AI 都不清楚。

工具在变，但问题没变。所以解决问题的方法论也没变——区分问题性质、设计执行节奏、积累有效记忆、设计协作边界。这四件事，不管用不用 AI，你都要做。

设计规范而不是制定流程

很多人以为规范是一套「必须按顺序执行的步骤」，其实不是。

好的规范是一套判断框架：告诉你遇到什么情况应该怎么处理，而不是告诉你每一步必须怎么做。

比如「临时区随手问，项目区认真设计」——这不是一个步骤，而是一个判断原则。遇到一个新需求，你先判断是临时区还是项目区，然后决定用哪种方式处理。这就是规范和流程的区别：规范告诉你在什么情况下做什么判断，流程告诉你每一步具体怎么做。

Harness Engineering 的本质，是设计一套能让你持续做正确判断的框架，而不是一套让你机械执行的流程。

从现象到方法论，从方法论到工具

这篇文章的思路是一层层往上走的：

  • 先从现象出发：人遇到什么问题，AI 放大什么问题
  • 再到方法论层面：PDCA 循环、OODA 循环，这些方法论已经存在了几十年
  • 再到工具层面：双区识别、三阶段、MEMORY.md、子任务、CI/CD

反过来，当你遇到一个新问题，思考路径应该是：这个问题属于哪个维度？这个维度应该用什么方法论来解决？这个方法论应该用什么工具来落地？

举例：AI 每次新会话都不记得上次做什么 → 属于「积累」维度 → 用上下文管理的方法论 → 用 MEMORY.md + 新会话给上下文这个工具。

再举例：AI 直接开干，做完发现不是你要的 → 属于「节奏」维度 → 用 PDCA 循环的方法论 → 用三阶段 + Plan Mode 这个工具。

这个三层结构（现象→方法论→工具）能帮你把零散的经验组织起来，形成一套可以迁移的思考方式。不只是「怎么用 AI」，而是「遇到这类问题，应该想什么」。

六、从今天开始

这篇讲了很多框架和规范，但核心想说的是：你不需要照搬任何人的做法。

你现在可以做的几件事：

  1. 想一个你最近反复踩的坑——把它写进 MEMORY.md，下次新会话第一件事就是告诉龙虾「我之前踩过这个坑，注意不要这样做」。
  2. 检查你现在的需求表达方式——你是给方向还是给接口？说「帮我优化这个函数」还是「找出性能瓶颈，给出具体行号和修改建议，不要动代码本身」？
  3. 想一个你已经做过两次的事情——设计一个最简单的流程，让第三次做的时候不需要重新思考。

这些都不需要学很多技巧，也不需要花很多时间。从最小的那件事开始，先做起来。

本系列后面还有一篇（05），会讲具体案例，看看这些规范在实际项目中是怎么落地的。思路和这里讲的一样：不是标准答案，是参考框架。用得上就借鉴，用不上就改，改成适合你自己的。

有问题欢迎留言，下篇见。