12 PDCA × 写代码/做事
写一行调一行就是 PDCA。你早就在做。现在你知道给它起名字了。
12.1 你已经在做的事情
你写一行代码，运行，看看报不报错。如果报错你改。如果正确你继续。
这就是一个微型 PDCA 循环。每写一行就是一次。
你不信？
- P：你想实现一个功能（比如"给这个按钮加一个点击事件"）。
- D：你写了两行代码。
- C：你运行，控制台输出了一个 undefined。
- A：你发现的代码哪里错了——少了一个参数。改好。
整个过程也许只需要 20 秒。你一天做几百次。你从来没有把它们叫做 PDCA，但你一直跑着这个环。
为什么写代码的人适合学 PDCA？不是他们需要学——是他们已经在用了，学了之后可以把这条环从"无意识"变成"有意识"，从而让它在更大尺度上的使用也生效。
12.2 写代码的 PDCA 四个尺度
你已经在跑最小的环（一行），还可以跑更大的环：
| 环的尺度 | 一圈多久 | 例子 |
|---|---|---|
| 单行/单函数 | 秒~分 | 写一行 → 跑 → 看结果 → 改 |
| 一个功能 | 分~时 | 写一个功能 → 手动测试 → 看通过与否 → 改或继续 |
| 一个模块/版本 | 天~周 | 做这个版本的需求 → 完成 → 跑测试/审查 → 复盘并定下个迭代标准 |
| 整个项目 | 月~季 | 定项目方向 → 分阶段执行 → 里程碑回顾 → 调整方向 |
你的"做事"里天然就有这么多层环。不是"你要不要用"——是你用什么工具让这些环由下而上都能对齐。
12.3 "调试"就是 PDCA 最典型的四个字母
调试的每一步：
- P：你有一个假设——"这个错误是因为变量 X 被覆盖了。"
- D：你在 X 被赋值的地方加一行 console.log。
- C：你重新运行，看看 console 的输出跟你的预期一样不一样。
- A：如果一样——你找到原因了，修复它（改环境/代码）。如果不一样——你修正假设（改 P），再跑一圈。
调试只有两种情绪："我找到原因了"和"我有了一个新假设"。
没有"这事太难了"、"这代码有问题"、"我真是菜"。 只有"我找到原因了（闭环成功）"和"我有一个新假设（再开一圈）"。这是 PDCA 给你的心态——失败和信息，不再分彼此。
☼ 例子：改一个 CSS 样式（自编）
你要让一个按钮居中。
- P：用
margin: 0 auto;应该能居中。 - D：加上了。
- C：刷新。按钮还是靠左。→ ❌
- A：假设错了。发现这个容器不是块级元素，margin:0 auto 对行内元素无效。改 P：要给容器加
display: block;再试。
第二圈：
- P：
display: block;+margin: 0 auto; - D：加上 display 属性。
- C：刷新。按钮居中了。→ ✅
- A：记住：要让块级元素才能用 margin 居中布局。这是一个经验。
一共两圈 + 不到 30 秒。但你有 P 和 C 在，你学到了一条 CSS 经验。如果你只是"试到居中为止"，你可能试对就不管了，下一次遇到同样的场景你还是折腾 30 秒。
12.4 把你的"做事"也当代码——可调式、可迭代
在做事的时候，很多人不敢"试"——因为试错了成本高。但在 PDCA 里，没有真错的"试"——只有"数据收集"。
假设你正在安排一个任务：写一篇周报。
- P：我想用一种"分三段的模板"来写。长这样：第一段本周进度、第二段遇到的问题、第三段下周计划。
- D：你第一周就按这个模板写了。
- C：写完了。你感觉如何？信息密度还可以，但第三段的"下周计划"每次都写得偏主观——缺少数据支撑。
- A：修改 P：把第三段改成"下周的量化目标（3 条以内）"。
然后你第二周继续转这个环。
做事情像写代码一样——你可以调试你做的事情的方法论。方法论本身可以 TDD：先写一个你认为可行的 P，然后 D 执行，C 去验证，A 去修改。跟改 CSS 完全一样。
☼☼ 例子：整理 Obsidian 笔记的 PDCA（自编）
你的第二大脑整理就是一条 PDCA 环在跑。
- P（组织标准）：每一篇笔记都要有 frontmatter（tags，date）、3 个以上的内部链接。
- D：你写了几篇。
- C：写完之后回头看：有些没 frontmatter，有些单篇没有链接。
- A：修改环境：你的模板里直接加
tags: []、links: []作为占位，让你开写的时候就已经有了。也可以在 obsidian 模板里预设。不需要靠"记性"——让系统自动帮你完成。
你不需要看完所有 Obsidian 教程。你只需要 PDCA 三番几次之后，把最卡住的地方一层一层解开。一个国民笔记体系就是这样长出来的——不是设计出来的。
12.5 PDCA 告诉你：不可能一次就好
我不打算安慰你说 "没关系，你可以多试几次"——这太鸡汤。我说的是事实：
没有任何一行有意义的代码是第一次编译就通过的。没有任何一个标准是第一次 P 就完美的。
写代码这件事本身就证明了 PDCA 的必要性：如果你预期"第一次就写对"，你就不会写——你会害怕写错。但如果你知道写完会根据错误再调一次、再跑一步，你就敢写了。
你的生活也这样。
你现在给自己定的时间管理表——它第一次运行不可能完美。不是因为你不努力，是因为它不可能第一次就完美。至少你需要的不是"完美"——你需要的是跑起来，跑一步调一步。
这一章要带走的东西：
- 写一行调一行的过程就是精细 PDCA 的神级体现。你每天做了几百次，没给它起名字而已。
- 做事像写代码——你不需要一次做对，你需要跑起来，然后调。
- 调试只有两种情绪——"我找到原因了"或"我有一个新假设了"。没有"我完了"。
- 你的时间管理表是代码——它的第一次运行不会完美，但你可以在每圈结束时修改它。
- 会 PDCA 的人，不在原地改完再出发。他们边走边改。
就这样。