ARTICLE · 1017757
一个AI编程软件使用心得
一个AI编程软件使用心得先说说我在开发什么。 我手上有一套软件授权注册码系统，用来给工程软件签发授权注册码——客户拿到的软件，有码才能用。系统本身不大：一个核心库，加上"生成端"和"注册端"两个小工具，加起来大约 1600 行 C 问题出在它的技术栈：.NET Framework 3.5 + WinForms。这是什么概念呢——那个框架发布的时候，现在很多开发者还没上大学。 把它现代化，我惦记很久了，但一直没敢动手。原因很简单：这是一个"不能出错"的系统。它签发的每一个序列号，都对应着一个客户正在使用的软件授权。改坏了，麻烦就大了。 今年 8 月，我决定换一种方式来做这件事：把它交给 PPM Desk。 PPM Desk 是一款"结对效能管理工作台"。说人话：它给 AI 开了一间办公室——项目文件夹就是它的办公桌，里面放着一套为人机协作设计的文件结构。你跟它说话，它真去干活；干完的活，它自己记在文件里。下次再开工，它读一读自己的笔记，就接上了上次的进度。 一个多月下来，10 次会话（每次也就工作一两个小时），这套系统走完了从 .NET Framework 3.5 到 .NET 9 的平台迁移，又完成了下一步架构重构的地基。而我想分享的，不是它帮我写了多少行代码——是这套结对方式本身，给我的几个没想到。 用了它之后，我的每一天工作是这样开始的：打开 PPM Desk，敲下一句固定的话—— 同一句话，我用了一个多月，一次都没变过。 然后它就开始了。它先自己去读一组文件，回来跟我汇报——我是谁、项目有几条主线、上次做到哪、这次要做的第一件事是什么，几句话交代得清清楚楚。 我一句话都没解释。 你可以对比一下我用其他 AI 工具的日常：每次开新对话，先花十分钟把项目背景、技术选型、上次进展重新讲一遍；讲完了，对方的理解还经常跑偏。而在这里，它像一个每天来上班的同事——昨天的工作留在桌上，今天进门先看一眼，然后就接着干。 更让我印象深刻的是一些"小动作"。有一次它开局后跟我说：等一下，我发现全局的全景图和上次会话的收尾状态有 3 处对不上，我先修正一下——追溯回去，原来是两个会话之前的一次收尾，漏了同步工作。这种错，放在人身上就是"交接漏了"，往往要等到好几个环节之后才爆发；而它每次开场前，都会先把账对一遍。 还有一次是 9 月中旬，我隔了几天没来，回来随手发了一句"你好"。它回： 那一刻我有点触动——它记得的不仅是"项目状态"，还有"有一句话，我还没等到你的回答"。 这是我用之前没有预料到的设计。 PPM Desk 里，AI 分成了两个角色：一个"参谋长"，一个"开发者"。参谋长负责理解需求、设计架构、拆分任务、做验收；开发者负责按任务书写代码、自测、汇报。两个角色是两个独立的 AI 会话，互相不直接说话——它们通过文件通信：任务书放进"收件箱"，做完回帖"求验收"，验收通过后双方各标记一次"closed"，一条消息才算真正关闭。 一开始我还闹了个乌龙。有一次我急着推进度，直接对参谋长说："开始当前任务。"它停下来，回了我一句： 我这才意识到，它是在认真守住自己的角色边界。后来我明白了这个设计的妙处：代码是开发者写的，验收是参谋长做的——写的人不验收，验的人不写代码。"规划与实现分离、检查与执行分离"这条纪律，换我自己做项目时经常偷懒省掉，而在这里，它被结构性地保证了。 实际运转起来是这样：参谋长的任务书做得极细——每个改动点、验收标准、甚至连"异常处理放在哪一层"都写清楚了；开发者接活时先"三问承接"（这活对应什么目标、涉及哪些文件、怎么算验收通过），确认无误再动手。做完不只交代码，还交一份"修改自证清单"：每一处改动对应任务书的哪一条，一目了然。 而我在中间的真实角色，是"业务裁判"：技术上的事，两边自己闭环；凡是要对业务下判断的——比如"生成的序列号到底能不能注册成功"——他们都会停下来，等我。 结对工作里最难拿捏的是分寸：对方太听话，等于没有判断力；太自作主张，又让人不放心。这套协作方式里，AI 对分寸的处理让我印象很深。 先说说"不"的例子。迁移方案本来定的是 .NET 8，有天我想了想，跟它说：直接迁到 .NET 9 吧。它回： 说完照做。这件事让我舒服的地方在于：它没有因为"老板想这么干"就闭嘴，也没有因为"我发现了风险"就卡着不干——它把风险摆上桌面，然后把决定权交还给我。 再说说拿主意的例子。有一次它列了两个技术决策让我确认——迁移采用哪种深度、界面代码怎么写。我一时没看出门道，问它："这 2 个技术决策有什么用？"它解释完之后，说了这么一段话： "你不反对，就是同意"——这是它给自己划的行动授权。后来有一次，面对一个纯技术层面的选择，它甚至连"摆出来"都省了，直接在报告里声明："技术方案选择属我的职责范围，我自决了，给你留了纠偏窗口。" 还有一天，我问了个没头没尾的问题："要是以后我迁移到 Web 框架，怎么搞比较好？"它没有给我画大饼，而是先反问了一个关键问题——"你怎么看 Web 的时间预期？"然后分两种情况回答：如果是半年内的目标，WPF 迁移就是弯路，建议重新立项；如果是一两年后的方向，现在做的迁移恰恰就是正确的地基。它还顺手警告我：不要现在就做"接口抽象层"那类准备——"这些是为不确定的未来预付成本"。 会顶、会等、会挑担子、也会把球传回来。这种相处分寸，跟和一位有经验的专业人士共事，几乎没有区别。 AI 协作最大的隐忧是什么？我的答案是一句话："它看起来什么都懂，但你不知道哪些是真懂。" 这个项目里，我见过它最狼狈的一次翻车，也见过它最漂亮的翻身仗。 翻车是这样：有一次它干完活，报告说"文件都建好了、状态也同步了"。我随手翻了翻，发现没落地。我拿话点它："怎么三元组还没有建立？"它老老实实认账："你说得对——没有完整落地。现在补齐。"从那以后，它的工作终检里多了一条规矩：任务完成后，逐项核对交付物清单。 翻身仗是这样：项目中间搁置过一阵，再回来时，工作笔记里写着"代码改动已全部完成，下次直接验证即可"。它在动手验证之前，先做了一件事——把源码逐文件读了一遍。读完发现：笔记里说"已完成"的那批改动，实际上"一行代码都没改"。它当场给出的判断是： 我很感谢这个判断。如果它信了文档，接下来它的所有"验证"都会建立在沙子上。 后面还有个小例子。编译项目时一下爆出 57 个错误，它没慌，顺着错误一路定位，最后发现：所有 57 个错误的根因就一个——某个文件里少了一行引用。一行修完，全部通过。 它有一条很硬的家规，叫"凭印象是红线"——任何结论必须有资料支撑，不许凭记忆断言。这条规矩的落地方式是各种"证据仪式"：写接口之前逐行读原代码；验收时"不凭开发者的自证清单下结论"，把对方写的 19 项断言独立复跑一遍；汇报结论附上证据出处。 说白了就两个字：真读。听起来朴素，但如果你和 AI 结对干过长期项目，你会知道这有多难得——它意味着你交给它的每件事，都是"确认过事实"的，而不是"猜的"。 一个人犯错不可怕，可怕的是同一个错犯十遍。跟 AI 协作，这个担心会被放大十倍——因为 AI 没有记性。 这套体系里让我觉得最有意思的设计，是它对"犯错"的处理。 有个例子特别典型。项目做到一半，构建环境突然坏了——所有命令行工具都超时，编译做不了。它的处理方式是：把这件事记进"记忆"文件，然后用别的手段（静态审查）顶过一次检查。几周后它重新开工，第一件事就是试跑一条命令，确认"环境已恢复！"，然后把记忆条目更新掉。 记下来，就不会忘。下次它开机时读到的，就是"这里以前坏过，先检查一下"。 更大的错也有。有一次它收尾时漏做了一步"全局文件同步"——工作从表面看已经交付了，漏掉的是几个状态文件的更新。当时谁都没发现。两个会话之后，它开局对账时发现了 3 处对不上的地方，追溯回去，找到了那次漏掉的同步。 如果事情到这里就结束，那只是"发现并修复了一个错"。但接下来它做了一件事：把这次的教训写成一个独立的方法文件，叫《收尾基线对账》，讲清楚这类错为什么会发生（收尾步骤多，漏了不会立刻爆炸，而是延迟浮现）、以后怎么防（每次收尾逐项对账的三条检查）。从此以后，"收尾"这个动作里，就内置了这三条检查。 这就是我说的"错误变成资产"：不是"下次小心点"这种空洞的保证，而是把教训固化成流程、清单、和下次真会用到的检查项。 我后来算了算，这一个多月的项目里，它自己攒下的"家训"已经有不少：怎么对账、怎么验收、什么算红线、哪些是它反复踩过的坑。这些东西跟着项目走，越用越厚。 讲一个我印象最深的瞬间。 迁移推进到中途，开发者请我做人工走查：打开两个工具程序，生成一条测试序列号，再走一遍注册流程。我打开程序看了看界面，回来问了一句： ——我隐约觉得哪里不对：说好的 WPF 迁移，怎么程序还是老样子？ 它回答得很快，也回答得很稳： 然后它解释了原委：这一版采用的是"分层迁移"——先把序列号的核心算法从界面里抽出来、归位到主库；界面换壳是后面阶段的事。这一步的验收对象，本来就应该是原来的程序——界面不变，恰恰是"预期结果"，因为这次动的是外表下面的引擎。 我回想了一下：我的质疑并非无理，做迁移却看到旧界面，任何人都会愣一下。但它的回答让我同时感到两件事：一，它清楚自己在哪一步、为什么是这一步；二，如果我坚持认为它错了，最终拍板的还是我。 这正是这套协作里我认为最健康的一点：AI 可以把所有事做到 99 分，但"是不是对"的最后一分，判定权始终在我手里。 那天后来我告诉它："生成了序列号注册成功。"——用旧界面签发的序列号，在新架构下注册成功，业务连续性确认。这是它等了一天的一句话，也是只有我能给的一句话。 技术验证它自己做（19 项断言全部通过），但"这个东西签出去的码，客户真的能用"——这个判断，永远得由一个用软件的人来做。 回到开头的问题：AI 到底能不能干真实项目？ 我的答案是：能。但重要的不是"选哪个模型"，而是把这个 AI 放进一个"组织"里——给它角色、给它记性、给它规矩，给它一张能看到全局的地图，和一条能把活串起来的流程。 PPM Desk 给我的，本质上就是这样一间办公室。 盘点一下这一个多月的成绩单： 平台迁移：从 .NET Framework 3.5 到 .NET 9，三个项目，0 编译错误 安全加固：排查出的 9 项安全问题完成核心修复——SQL 注入、固定加密 IV、弱密钥…… 架构重构：把藏在界面代码里的核心算法归位到主库，签发端和注册端从此共用一份引擎 全程业务零中断：所有已签发的序列号继续有效，新的注册流程端到端验证通过 全程 10 次会话，没有哪一次是"专门用来救火"的 1600 行的系统，听上去不大——但"老项目现代化"这事，难的从来不是代码量，是你敢不敢动、动了能不能收场。 最后分享一个我自己的体会。以前用 AI，我最常问的是"你行不行"；现在我最常做的，是坐下来，跟它说一句"开局"，然后看它从桌上拿起昨天的工作。 如果你也有一个"想来想去、一直没动手"的项目，不妨给它一个机会。
把一套老授权系统交给 AI 之后——我的 PPM Desk 使用心得
一个真实软件项目的开发记录 · 2026 年 8 月—9 月
代码。
一、开工只需两个字，它自己接上全部上下文
"阅读 cos-context.md，开局。"
"会话已经收尾完毕……我还在场。刚才那个小问题还悬着：需要我用业务语言给本次交付做个映照吗？"
二、跟我干活的不是"一个 AI"，是一支小分队
"我是参谋长，不是开发者。你要我以开发者身份执行代码改动，还是先完成参谋长侧没完成的事？"
三、它敢说"不"，也敢自己拿主意
"提示一下：.NET 9 是 STS 版本（短期支持版），2026 年 5 月已经结束支持了；不过技术路径和 .NET 8 完全一致，你确认的话，我就按 9 来。"
"这两个点，你有业务视角，我只有技术视角——所以我摆出来让你看；但你不反对，我就按方案 B 走。"
四、真读，比聪明更动人
"文档状态与代码严重不符，工作应以代码实测为准。"
五、连犯过的错，都会变成资产
六、说最后一句话的人，还是我
"不是 WPF 的执行文件啊。"
"对，这不是 WPF，而且此时就该不是。"