先说结论如果只让我用一句话总结这次从v1.0到v1.3.0的实践我的结论是Vibe Coding 不是“让 AI 帮你多写点代码”而是把“需求澄清 → 计划拆解 → 快速实现 → 高频验证 → 文档沉淀 → 版本追溯”这条闭环压缩到极短周期里。HTML Document Center这个本地工具就是这条闭环的一个非常典型的样本它从一个解决“HTML 审阅文件太散、浏览器打开不顺手”的小工具出发只用两天不到就长成了一个同时支持HTML和Markdown的本地文档工作台但同一时间它也把 Vibe Coding 最危险的一面暴露得很彻底——你可以非常快地把代码推到v1.3也可以同样快地把 Git 历史留在v1.1。这次复盘最值得记住的不是某个具体功能而是三个更底层的洞察Plan 不是文档而是施工图。当docs/superpowers/plans/写得足够细AI 的产出会明显更稳定。Changelog 不是总结而是运行日志。高频迭代时真正帮你回放“发生了什么”的不是记忆是时间轴。Git 不是可有可无的收尾动作而是最后一道现实约束。没有 commit再漂亮的方法论最后都会悬空。这篇文章不讲空泛观点。我会直接基于CHANGELOG.md、两份Superpowers plan、ITERATION-SOP.md和核心代码文件拆开讲这件事到底是怎么发生的。一、项目到底是什么HTML Document Center是一个本地文档工作台定位很朴素扫描指定目录里的文档用目录树统一展示在 iframe 里打开文件自动注入最小编辑能力编辑后 2 秒自动快照关闭时弹出三选项覆盖源文件 / 另存为审阅版 / 丢弃它最早是一个HTML 工作台到v1.3.0才扩成HTML Markdown 双栈工作台。从代码和文档看项目的骨架很清晰后端server.pyaiohttp服务负责目录扫描、文件读取、快照与保存、配置管理前端 SPAweb/app.js负责目录树、iframe 打开、状态管理、保存对话框、上次会话恢复运行时注入层saver-runtime.js负责 iframe 内的编辑监听、脏状态、自动快照、postMessage通信文档与流程层CHANGELOG.md、CHANGELOG.html、ITERATION-SOP.md、docs/superpowers/plans/*.md从体量上看它不是一个“玩具 demo”但也还没大到失控文件行数server.py747saver-runtime.js374web/app.js789web/index.html131web/md-editor.html224CHANGELOG.md185CHANGELOG.html540README.md149合计3139这几个数字很重要。因为它说明这不是靠“大量业务代码”堆起来的复杂系统而是靠架构清晰、反馈快速和规则严明堆起来的效率系统。二、第一幕Superpowers 四件套是怎么真正落地的很多人讲 AI 编程会停留在“会不会写 prompt”“能不能让模型多输出一点代码”。但这次实战里真正起作用的反而不是 prompt 本身而是围绕 prompt 搭起来的流程约束。ITERATION-SOP.md的第 0 条铁律写得非常狠本项目的任何迭代/新开发一律走 Superpowers Skills不允许直接动手写代码。这句话听起来像官话但配上后面的细则它就不是口号而是方法多步任务动手前先brainstorming→writing-plans有 plan 后用executing-plans按 checkbox 执行修功能或修 Bug走test-driven-development遇到异常先systematic-debugging声称完成前必须verification-before-completion改代码时必须同步CHANGELOG.md和CHANGELOG.html这套东西的价值不在于“流程看起来很全”而在于它把 AI 最擅长和最不擅长的事情切开了。1. AI 最擅长的是局部生成不擅长全局约束如果不给 AI 明确的骨架它会默认往“局部最优”滑把眼前这个按钮先做了把这个 CSS 先改了把这个报错先消掉这样短期很爽但很容易出现三种问题需求被过度解释比如用户说“一级目录就够了”结果做成了“深层目录扁平化”后面又得回滚。功能修好了边界坏了比如新增 Markdown 支持时如果忘了_auto-save的后缀逻辑.md快照会被写成.html。局部对系统不对某个接口能跑但CHANGELOG没同步、验证没留痕、Git 没 commit结果整体仍然不可追溯。Plan 的作用就是提前把这些“系统级约束”写进施工图里。2. 两份 plan像两代成熟度样本这个项目里一共能看到两份关键的Superpowers plan2026-04-18-ux-refinement-v1.1.md2026-04-19-md-support.md它们非常像两个阶段的成熟度切片。第一份v1.1plan是典型的“施工图雏形”这份 plan 的目标很明确修复v1.0的三个 UX 顽疾——目录遮挡、缩放设计混乱、三栏垂直空间浪费。它按 5 个任务拆解顶栏三合一 DOM 重组目录从浮动改推挤布局缩放档位与默认值重构删除 iframe 上方冗余 saver 工具栏回归截图 CHANGELOG共27 个 checkboxSuccess Criteria 也写得很像验收单例如目录打开时编辑区必须同步收缩缩放按钮必须是25% / 50% / 75% / 100% / 125% / 150%顶栏高度必须只有44pxOPPO v2 这类已有原生编辑器的页面iframe 上方不能再出现一条注入工具栏它的问题也很典型结构已经对了但勾选痕迹没有被完整回写。也就是说v1.1这份 plan 更像一个优秀的施工图模板而不完全像一份被严格维护到底的执行日志。它已经足够指导 AI 干活但还没形成“plan 本身就是交付物”的肌肉记忆。第二份v1.3plan已经是成熟工作流2026-04-19-md-support.md就明显进化了。这份 plan 的目标不是修小问题而是做一次真正的能力扩展给 DocCenter 增加 Markdown 全链路支持但要求 HTML 原有能力 0 退化。它拆成 5 个任务后端扫描/路由扩展 MD 支持MD 编辑器壳子页面saver-runtime.js扩展 md 分支前端app.js适配端到端回归 CHANGELOG双写总共35 个 checkbox而且这 35 个步骤都被明确标成了- [x]。更重要的是这份 plan 的粒度已经到了“AI 很难跑偏”的程度。比如它不是泛泛地说“支持 md 保存”而是把隐式坑直接写出来handle_save的另存扩展名必须跟随源文件 suffix_clean_auto_save要按源文件 suffix 过滤handle_snapshot不能再把.md快照写成.htmlpostMessage消息名保留不变避免向后兼容问题这就是 plan 的真正价值它不是在描述结果而是在预埋坑位。3.verification-before-completion为什么重要这次最打动我的不是 plan 本身而是它和验证闭环绑在一起。在v1.3的 changelog 里验证不是一句“已测试通过”而是有明确的证据/api/tree返回md_nodes251 html_nodes305/api/file?path.md返回 6841 字节壳子 HTMLmd-input、md-preview、marked引入、modemd等关键字段校验通过快照扩展名、overwrite 备份扩展名、清理逻辑都被验证HTML 文件回归仍然保留原有注入能力无modemd残留这一步本质上在解决一个很现实的问题AI 可以非常自信地说“改好了”但真正可信的不是它的话而是它有没有留下可复验的证据。4. 最关键的不是 Skill而是“把 Skill 写进 SOP”很多团队用 AI 最大的问题不是不会用工具而是工具只停留在“知道有”。这个项目的高明之处是它没有把Superpowers当外挂而是直接写进ITERATION-SOP.md变成项目级硬约束。于是 AI 不再是“有空时就顺手用一下某个 Skill”而是没有 plan不准动手改了代码必须改 changelog宣称完成前必须给验证这一步的意义很大。因为一旦规则写进项目而不是写在脑子里AI 协作才会从“高手手感”变成“团队机制”。三、第二幕v1.0到v1.3.0这 10 个版本到底怎么长出来的如果从时间轴看这个项目并不是匀速增长的而是三个阶段v1.0把骨架立起来v1.1v1.2.x围绕体验高频打磨v1.3.0在原架构上做一次“0 退化扩展”阶段一v1.0先把最小可用闭环做出来v1.0的能力其实已经把产品的核心价值说清楚了aiohttp后端 5 大 API/api/tree、/api/config、/api/file、/api/snapshot、/api/save目录树扫描 白名单路径安全校验编辑/批注 2 秒后自动快照到_auto-save/关闭时弹出三选项保存对话框saver-runtime.js动态注入工具栏或嗅探原生编辑器极简顶栏、目录切换、缩放控制如果把这版抽象成一句产品定义它其实是“把散落在本地文件系统里的 HTML 审阅资产拉进一个统一可编辑、可回退、可另存的工作台。”这里最关键的不是 UI而是它一上来就抓住了两个决定长期生命力的点第一安全边界从第一版就有server.py的开头就写明了所有路径操作都必须经过_resolve_safe()校验路径必须在scan_roots白名单内。这说明作者没有把它当成“本地脚本反正自己用”而是把它当成了一个要长期运行的本地服务。这种心态差异很重要。因为很多 AI 写出来的小工具一开始就埋下“以后一定会炸”的路径/权限洞。第二自动快照从第一版就有很多产品会先做“能编辑”后补“能恢复”。这个项目是反过来的先保证改动不丢再谈编辑舒服不舒服。这是非常对的优先级。因为文档工作流里用户最害怕的不是界面丑一点而是“改了半小时丢了”。阶段二v1.1到v1.2.6真正把“爽感”磨出来如果说v1.0证明了“能用”那v1.1到v1.2.6才真正把它打磨成“愿意持续用”。v1.1一次典型的 UX 结构性翻修v1.1不是加功能而是重新整理界面秩序。它主要做了四件事顶栏三合一把原本独立的一整条工具栏压回44px顶栏目录推挤布局从浮动遮挡正文改为flex推挤目录展开时编辑区同步收缩缩放档位重构从含糊的Fit改成明确的六档默认75%双工具栏去重已有原生编辑器的页面不再重复注入 DocCenter 工具栏这版的本质不是“美化”而是把认知负担降下来。例如“顶栏三合一”本身不创造新能力但它一下省出48px垂直空间目录从遮挡改成推挤也不创造新能力但它让“打开目录时还能预览正文”这件事从别扭变成自然。这类改动往往最容易被低估但恰恰最影响留存。v1.2开始从“工具”走向“工作台”v1.2的关键词是让文件切换和定位更顺手。主要变化包括目录从全平铺升级为更聚焦的结构一键收起目录树自动恢复上次会话与缩放级别文件/文件夹 icon 菜单Finder 打开、复制路径、复制名称设置面板里增加CHANGELOG入口这版很有意思的一点是它已经开始把“工作上下文”当成一等公民。比如“上次会话恢复”看似小功能但对这种本地工作台来说非常关键。因为用户用它不是随机浏览一个页面而是反复在固定几个文档间切换。一旦能回到上次工作位置工具就从浏览器标签页变成了真正的工作现场。v1.2.1到v1.2.61 小时 48 分钟 6 版Vibe Coding 的高密度样本这六个 patch 是整篇复盘里最像“Vibe Coding 现场录像”的部分。从13:16到14:48一共发生了 6 次快速迭代v1.2.1把“全部收起”按钮从“像收起侧边栏”改成“明确表示折叠文件夹”v1.2.2首次刷新默认展开侧边栏避免“恢复了文件但看不到自己在哪”v1.2.3放弃过度扁平化回到真实目录嵌套v1.2.4修复脏状态误报v1.2.5删除多余的按钮v1.2.6修复会话恢复覆盖 Bug这六版之所以重要不是因为它们功能多大而是它们把 Vibe Coding 的一个核心特征暴露得很清楚不是“大版本规划”而是“上线即反馈反馈即修正修正即沉淀”。这和传统“攒够一波再发版”的思路完全不同。它更像是先让用户摸到观察哪里最别扭立刻用一个 patch 把别扭消掉再从下一轮用户反馈里看系统性问题从结果看这六版里最有价值的不是按钮位置而是两个非常典型的 Bug 修复。阶段三v1.3.0不是重写而是架构复用的胜利v1.3.0最大的价值不是“支持了 Markdown”而是它几乎没有推倒原架构只是在已有链路上做了后缀分流和模式分流。Changelog 里把这件事写得很清楚后端handle_file按后缀分流.html走原inject_saver.md走render_md_shell()saver-runtime.js通过window.__DOC_CENTER__.mode md做模式分流postMessage协议名字完全不变app.js只做最小范围适配例如图标和文案扩展这意味着 Markdown 支持不是“复制一套新系统”而是在原来的工作台骨架上多插了一条支线。这才是我认为v1.3.0最成熟的地方功能扩展靠分流而不是靠复制。当你能用“后缀分流 模式分流 协议不变”去扩一个新能力说明你的第一版架构没有白做。四、第三幕三个 Bug 故事暴露了 Vibe Coding 最容易失手的地方前面讲的都还是“怎么越做越顺”但真正能让人长记性的往往是翻车。这次最有代表性的有三个。Bug 1脏状态误报——AI 很会“看到变化”但不一定知道“什么才叫用户编辑”这是v1.2.4修掉的问题。现象用户切换文件时系统频繁弹出“未保存修改”对话框但实际上并没有编辑任何内容。根因问题出在saver-runtime.js的观察策略它原本的MutationObserver监听了过多 DOM 变化尤其包括属性变化。页面自身的动画、CSS 过渡、滚动高亮都被误判成“用户改了内容”。这类问题非常典型。因为 AI 在写这类逻辑时天然倾向于“宁可多抓不要漏抓”。但在交互系统里误报比漏报更伤体验。漏报顶多偶发一次误报会直接让保存对话框变成骚扰。解法这次修复很漂亮直接上了三道护栏用户交互窗口只有最近800ms内发生过keydown/mousedown/paste/cut/drop后续 DOM 变化才有资格算编辑忽略 attributes只监听childList characterData延迟 1 秒绑定避开页面初始化阶段的 DOM 抖动这个修复背后的启发很大“看到变化”不等于“理解意图”。AI 写监听器时最容易犯的错就是把技术上发生的变化误当成用户意义上的变化。要修这种问题靠的不是再多写几行 if而是先把“什么才算真编辑”这个定义想清楚。Bug 2会话恢复被覆盖——自动化越顺越要警惕后台流程反噬前台状态这是v1.2.6的问题。现象用户打开 A 文件后刷新浏览器结果恢复出来的不是 A而是更早打开过的 B。根因问题不在“恢复失败”而在“恢复流程本身又把状态写回去了”。原来的openFile()每次都会无条件写last_session。而会话恢复流程本身也是tryRestoreLastSession → openFile(silent)。于是多 tab 场景下后台 tab 在恢复自己的旧状态时又把last_session覆盖回去结果把前台 tab 的新选择冲掉了。这类 Bug 特别有代表性因为它不是逻辑不会写而是自动化链路和用户主动作业链路混在了一起。解法修复思路非常干净openFile()增加opts.silent恢复流程不回写last_sessionsaveLastSession()增加document.visibilityState hidden保护后台 tab 禁止自动写入这给了我一个很强的提醒只要系统里同时存在“用户主动触发”和“系统自动触发”两条路径就一定要把它们在状态写回层面分开。否则你以为你做的是“自动恢复”实际做出来的是“后台任务偷偷抢状态所有权”。Bug 3Markdown 快照扩展名连锁——AI 擅长复制路径不擅长主动挖出隐式假设这是v1.3.0中最值得学习的一类问题。表面问题如果直接把 HTML 的快照与保存逻辑复用到 Markdownhandle_snapshot会继续把快照写成.htmlhandle_save的 pre-overwrite 备份也可能写成.html。这看起来只是“扩展名不太优雅”但实际上是连锁问题语义混乱明明是 Markdown 草稿却长成 HTML 文件名清理逻辑失真_clean_auto_save()如果按.html过滤就无法正确处理.md备份误删风险当备份与快照开始共享前缀后清理逻辑可能把本该保留的 pre-overwrite 备份一起删掉根因这不是一个“写错变量”的低级错误而是典型的隐式假设外溢系统最初是 HTML-only于是很多地方默认把“文档”理解成“.html 文件”。当你扩展到第二种文档格式时这些历史假设会从不同角落一起冒出来。解法这次修得很系统快照文件名跟随safe.suffix另存和备份文件名跟随safe.suffix_clean_auto_save()按源文件 suffix 过滤额外引入backup_prefix保护pre-overwrite-*不被快照清理逻辑误伤这个故事最值得记住的不是“.md扩展名也处理了”而是做能力扩展时AI 能很快复制主路径但你必须主动追问这个系统里哪些地方偷偷默认了旧世界五、真正让我服气的地方v1.3.0为什么是一次漂亮的扩展很多 AI 项目一旦进入第二个能力扩展代码质量会迅速坍塌。原因通常不是模型不够强而是第一版的接口、状态和职责边界没有想清楚导致新功能只能复制一套新逻辑。DocCenter到v1.3.0还没有出现这个问题核心原因有三点。1.iframe saver-runtime postMessage这个中间层抽象得足够稳HTML和Markdown的编辑形态完全不同HTML 偏 DOM / contenteditable / 批注Markdown 偏 textarea / 文本 / 实时预览但它们最终都能统一接到同一条协议上iframe 内告诉父窗口我 ready 了我变脏了我快照成功了你来取我的内容你把我标记为 clean只要协议稳定iframe 里的实现再不同父窗口都不用重写。2. 后端不是“按页面类型分系统”而是“按后缀分路由”后端的扩展方式很克制.html继续注入saver-runtime.js.md先render_md_shell()包成一个 HTML 壳子再交给同样的 iframe 体系去处理这一步非常妙。因为它避免了“前端需要同时管理 HTML 页和原生 Markdown 页两种打开方式”。换句话说Markdown 并没有破坏前端的世界模型它只是换了一层壳继续假装自己是 iframe 里的一个可编辑页面。3. 前端只动最小必要集v1.3.0对app.js的改动极少这恰恰说明抽象成功。如果一个新能力上线需要你把前端状态机、后端接口、保存流程、对话框、目录树、会话恢复全部重写一遍那不是功能强而是前一版架构根本没抽稳。而这里不是这样。这里更像目录树多认一种node.type图标从扩到文案从“HTML 文件”改成“文档”能做到“新功能很大改动点很少”就是架构设计最实在的胜利。六、Vibe Coding 到底适合什么不适合什么聊到这里必须把边界讲清楚。否则很容易把这次成功误读成“以后所有项目都这么干”。适合的场景这套方法特别适合以下类型1. 闭环短、反馈快的本地工具像DocCenter这种工具有几个天然优势需求具体反馈即时验证成本低风险边界清晰用户本人就是高频使用者在这种场景里AI 的“快速试错 快速修正”优势会被放大。2. 能被明确拆成任务树的功能扩展比如 Markdown 支持这种需求非常适合写 plan扫描层怎么扩路由层怎么分流编辑器壳子怎么做保存链路哪些地方会隐式假设 HTML验证点有哪些只要能拆到这种粒度AI 的执行稳定性就会很高。3. 用户体验型问题很多v1.2.x的 patch其实都是体验问题不是算法问题按钮会不会误解默认展开还是默认收起高亮路径够不够明确是否会误弹保存对话框这类问题特别适合高频小步迭代。不适合的场景但它也有明显边界。1. 外部依赖重、验证慢的系统如果一个改动需要长周期联调多方系统配合一周后才能看到结果失败成本很高那就不适合走这种极高频 patch 节奏。因为反馈一旦变慢Vibe Coding 的最大优势就丢了。2. 规则没写清的复杂业务AI 非常擅长执行明确规则但很容易在模糊业务里脑补需求。v1.2.3的“扁平化误解”已经是一个轻量例子。如果放到更复杂的业务系统里这类误解可能会放大成架构级返工。3. 对版本治理要求高但团队又没有 Git 纪律的项目这是这次复盘最重要的反例。如果团队能高频迭代却不能同步 commit、tag、记录版本那么节奏越快历史越混乱。最后你只会得到一个“现在能跑但不知道怎么走到这一步”的黑箱。七、最痛的一课为什么说 Git 才是最后一道防线现在说最关键的问题。查看仓库历史时我看到的是HEAD - main, tag: v1.1更早是tag: v1.0工作区却已经包含了v1.2、v1.2.1 → v1.2.6、v1.3.0相关改动换句话说Git 历史停在v1.1而真实系统已经漂到了v1.3.0。这中间悬空了 8 个版本节点v1.2v1.2.1v1.2.2v1.2.3v1.2.4v1.2.5v1.2.6v1.3.0这是一个非常典型、也非常危险的 Vibe Coding 后遗症。为什么会这样因为高频迭代会制造一种错觉代码已经好了页面也能看changelog 也写了当下问题也解决了于是 commit 会被潜意识地归类为“晚点再说的收尾动作”。但真相恰好相反。commit 不是收尾动作而是把这次工作从“临时状态”提升为“可追溯状态”的那一刀。没有这刀你拥有的只是一份现在能跑的代码若干份 changelog 文字一堆已经混到一起的工作区改动你失去的是哪一版引入了哪个能力哪个 Bug 是在哪个提交修掉的某个 patch 回退时应该回退到哪里某个版本是否真的和 changelog 对齐为什么说方法论只能治到 80 分这次最值得警惕的就是有 plan有 SOP有 changelog有验证按理说已经很完整了但 Git 断层仍然发生了。这说明什么说明流程文档和验证证据只能帮你把“做得更对”这件事做到 80 分剩下 20 分必须靠版本控制把现实钉住。Plan 告诉你该怎么做。Changelog 告诉你做了什么。验证告诉你现在能跑。但只有 Git commit 能告诉未来的你“这一刻的系统状态已经被正式命名、切分并冻结了。”这也是为什么我现在越来越认同一句话AI 可以加速开发但版本控制才负责让开发结果进入现实世界。八、如果让我把这次经验抽成一套可复制方法我会怎么说我不会把它总结成“多用 AI”。这太空。我会把它总结成下面这 7 步Step 1先把问题说成“系统变化”别只说成“想加个功能”例如这次不是“想支持 md”而是目录树要同时扫.html和.mdiframe 打开逻辑要兼容两种文档保存链路要保留三选项一致性快照和备份要跟随后缀上次会话恢复要扩到 mdHTML 原有能力不能退化一旦你把需求写成系统变化AI 才不会只盯着那个表面按钮。Step 2把 plan 写到足够细细到能提前暴露隐式假设一份合格的 AI plan不该只是改前端改后端测一下而应该像v1.3那样连旧世界的隐式假设都提前点名。Step 3优先复用已有协议不要第一反应就是开新分支、造新系统这次v1.3.0最漂亮的地方就在这里协议不动父窗口不动保存对话框不动只在后缀路由和运行时模式上分流这就是“架构先赢一次后面功能跟着赢”。Step 4Bug 修复不要只修现象要修定义脏状态误报的本质不是“监听太多”而是“什么叫编辑”定义错了。会话恢复覆盖的本质不是“恢复出错”而是“自动流和手动流争夺状态写回权”。这类 Bug 一旦只盯现象修往往会在别的地方再长出来。Step 5让 changelog 成为单一事实来源而不是事后补作文这次CHANGELOG.md非常有价值因为它不是“发版总结”而是每次 patch 的问题/根因/解法都被留下来了。所以后面写这篇复盘时我不是在靠记忆而是在读时间轴。Step 6每次宣称完成前都留下可复验证据“我测试过了”没有意义。有意义的是/api/tree返回了多少 md/html 节点壳子 HTML 多大、关键字段在不在快照文件后缀对不对回归 HTML 能力时有没有残留未来团队越依赖 AI这种证据化验证就越重要。Step 7把 commit 当版本切片不要当卫生动作这是我想强调三遍的最后一条。Vibe Coding 可以很快。但快不等于连续不切片。如果你发现自己已经在一个下午发了 6 个 patch却还没做一次 commit那就不是“效率高”而是在主动制造历史断层。九、给下一个项目的直接 Checklist下面这份清单是我认为可以直接复制到下一个 AI 工具项目里的。立项前把需求写成“系统变化”不是写成一句模糊愿望先定义什么算成功什么算退化明确哪些旧能力必须 0 退化先想清楚状态边界谁负责保存、谁负责恢复、谁负责快照、谁负责验证动手前先写plan而且要有Why / Files / Steps / Success Criteria关键步骤必须是 checkbox可追踪把隐式假设提前写出来例如路径、后缀、协议、缓存、回退逻辑明确哪些地方必须复用哪些地方允许新建实现中优先改分流不要优先复制每次只解决一类问题功能、体验、Bug、架构不要搅成一团Bug 修复必须写出“问题 / 根因 / 解法”三段式高频 patch 时优先保证 changelog 连续不要靠脑子记完成前跑真实验证不接受“应该没问题”留下关键命令输出或结构性证据检查旧能力是否真的 0 退化同步更新CHANGELOG.md和CHANGELOG.html做一次Git commit把当前状态正式切片复盘时回看是不是某个需求被过度解释了回看哪些 Bug 其实是“定义错了”而不是“代码写错了”回看有没有地方是靠重复复制撑起来的回看 changelog 是否足够支撑一篇复盘文而不是只能支撑回忆十、尾声这次实践真正证明了什么回到最开始那个问题这次从v1.0到v1.3.0的实践到底证明了什么我认为它证明了三件事。第一AI 写代码真正带来的不只是速度而是“更细粒度的迭代可能性”以前很多小问题你懒得修因为改动太碎、验证太麻烦、性价比不高。有了 AI 之后v1.2.1 → v1.2.6这种 1 小时 48 分钟 6 个 patch 的节奏开始变得现实。这不是单纯的“更快”而是以前不值得做的小优化现在值得了。第二AI 不是替你做产品判断而是把你的判断放大这次做得好的地方本质都不是 AI 自己想出来的默认展开侧边栏是因为理解了“可见性胜于记忆”不重复注入工具栏是因为理解了用户已有工作流Markdown 用壳子复用 iframe是因为先想清楚了架构边界AI 很会加速但方向还是得先对。第三越是高频迭代越要把“流程、证据、版本”当成产品的一部分如果没有ITERATION-SOP.md、没有 plan、没有 changelog、没有 verify、没有 commit这次项目也许仍然能做出来但不会有今天这么强的可复盘性。而我越来越相信一个 AI 项目真正的成熟标志不是“功能多”而是“你能不能清楚地回答它为什么这么设计它是怎么变成现在这样的以及如果明天坏了你该从哪里查起。”DocCenter这次实践已经把前 80% 做到了。剩下 20%就是那句最朴素、也最容易被忽略的话别忘了 commit。附录 A版本时间线摘要版本时间核心变化v1.02026-04-18首版发布目录扫描、iframe 打开、自动快照、三选项保存v1.12026-04-18顶栏三合一、目录推挤布局、缩放重构、双工具栏去重v1.22026-04-18 13:00聚焦式目录、会话恢复、文件/文件夹 icon 菜单、CHANGELOG入口v1.2.12026-04-18 13:16“全部收起”按钮消歧v1.2.22026-04-18 13:23首次刷新默认展开侧边栏v1.2.32026-04-18 13:40放弃扁平化恢复真实嵌套v1.2.42026-04-18 13:55修复脏状态误报v1.2.52026-04-18 14:05删除冗余按钮v1.2.62026-04-18 14:48修复会话恢复被覆盖 Bugv1.3.02026-04-19 16:20Markdown 支持后缀分流、模式分流、协议复用、HTML 0 退化附录 B关键文件索引ITERATION-SOP.md项目级流程铁律docs/superpowers/plans/2026-04-18-ux-refinement-v1.1.mdv1.1UX 翻修施工图docs/superpowers/plans/2026-04-19-md-support.mdv1.3.0Markdown 支持施工图CHANGELOG.md版本时间线与问题/根因/解法记录server.py扫描、路由、快照、保存、会话恢复saver-runtime.js脏状态、自动快照、iframe 通信核心web/app.js目录树、打开文件、保存对话框、会话恢复web/md-editor.htmlMarkdown 编辑器壳子页面附录 C这次最值得反复看的三个设计点分流优于复制.html/.md走不同入口但最终复用同一套工作台骨架协议优于页面形态不管内部是 DOM 还是 textarea外部只认ready / dirty_changed / snapshot_ok / html_content证据优于自信真正撑起复盘的不是“我记得当时怎么改的”而是 plan、changelog、验证输出和 Git 历史