我用AI四天给儿子写了个考试系统,但你千万别信什么“一键生成”的童话

对AI，我们像不像暗恋隔壁班花？

每个人都知道AI是趋势，内心深处很想用，但真上手了，往往不知道怎么用，更不知道怎么用好。

这种感觉，太像看上了隔壁班的班花。

你知道她很美，找机会接触了几次。初次见面，感觉特别美好，她不止长得好看，还挺会聊天。可聊着聊着，你发现她根本不懂你，她说的话越来越不像你所想象的。你会慢慢觉得，这可能不是你的菜，或者，你也不是她的菜。

这，就是绝大多数人用完AI的感受。

五一放假前，学校通知假期后进行信息中考，我看着初二儿子信息中考的模拟题，一堆基础知识和常识题，上周模拟考试，实操满分，选择题却错了一半。这像极了驾考科目一，死记硬背不行，得靠模拟系统猛练。一个念头闪过：我要用AI给儿子写一个微机考试模拟系统！

但结果会怎样？是收获一个“贤内助”，还是在反复拉扯中心灰意冷？我想通过这4天真实的“人机协作”经历，和大家聊聊，如何守住初心，共赴未来。

惊艳：它快得像老板眼里的“超理想程序员”

我把需求喂给了AI。4轮对话，34分钟，它就确认了初稿需求。

中间竟然还自主向其他agent征求意见，这让我很惊喜。

只要你把核心功能说清楚，它会像个优秀的产品经理一样帮你完善，你只负责确认，感觉太棒了！

再4轮，32分钟，需求分析和系统设计完成。从架构到数据库，再到风险管理，考虑得比一些中级程序员都周全。

更惊艳的是——3分钟后，一期代码写完了！无论中级还是资深程序员，都不可能达到这种效率。简直是所有老板梦寐以求的超理想程序员。

回归现实：想象很丰满，AI很骨感

因为超乎想象的编码效率，让我迫不及待想要试用。

结果现实给了我当头一棒。

格式和信息无法完全匹配，题库文档格式复杂且不统一，还缺解析内容。

接下来，我像个业务方，指挥着AI“产品经理”和“程序员”，反复确认规则，让它理解、完善、改文档、写代码。

80分钟，十几轮对话后，第一批题库终于导入。

我激动的心，颤抖的手，点开了“随机练习”。

然后心就凉了。——它一次吐出了全部10道题，根本没法答！说好的“发一道做一道”呢？

回归软件工程的本质：别把AI当神仙，把它当最毛躁的实习生

问题出在哪？我翻开“需求设计文档”，恍然大悟：AI比人类程序员还不愿意写文档！说好的设计文档只是个目录，像极了被迫应付差事的我们。

到这里，可能30%的人已经放弃了。但真的不用。你只需要一点耐心，把被AI丢掉的需求，一点点找回来。

这时一定要冷静，我总结了几个保命要点：

立规矩：先告诉Agent，停下来，没我确认不准改任何东西。
先复盘：让它回顾并复述一遍需求，别以为它都记得。
忌发散：修改别用开放题，你知道的细节就直接告诉它，别考验它。这时候联想跑偏的代价，大多是灾难性的。
5必问：原始需求是什么？现在怎么实现的？你打算怎么改？有什么风险？怎么测试验证？
严守流程：确认逻辑 > 更新文档 > 编码实现 > 核对一致性 > 验证测试。

再次经过29分钟，一份从简陋目录变为专业规范的需求设计文档终于出炉。

虽然复盘花了一个多小时，但代码修改依然是稳健的3分钟，加上核对测试，我们终于可以再次试用了。

效果，还真的不错！

很多文章到这里就该总结成功经验，让你误以为AI通宵就能搞定一切，如童话般完美。但我必须告诉你——这才刚刚开始。

抠细节：详细测试，不放过每一个细节，是基本素养。

建规则引擎：对复杂或琐碎的规则，建立独立规则引擎比靠AI每次分析更可靠。

建AI操作审核流程：需要AI介入的环节，必须有规范的审核流程（没有一句话自动完成一套系统的神话！）

规范项目管理：比如规范项目目录，对于项目的持续有效管理是必不可少的。
建立系统的路书：ReadMe，是保障每次重启、重置后Agent能够再次正确执行的关键。
建立标准的变更流程：严格保持文档与程序一致，避免需求变更造成整体混乱

不要倒在黎明前：和AI的“失智”与“崩溃”作斗争

这下应该可以稳定运行了吧？

可他又玩起了失联！是不是绷不住，想要放弃？

其实是你的耐心被AI的高效降低了n个数量级，或者说你错误的认为AI像神仙一样翻个跟头就可以十万八千里。要知道到目前为止也才过去了17个小时（还包含一个晚上），在传统软件项目里，都还没有开启动会呢！

调整openclaw单次会话最大Token数配置后，回归了正常。

这下可以稳定持续的运行了吧，可当十几轮会话之后，

Agent会忍不住插嘴加代码，会改程序输入输出，甚至第二天再用时，就找不到程序入口了。

这时，“红线规范”是保命的关键。你必须通过Agents.md入口、长期记忆等手段，给它划出清晰、不能逾越的红线：哪些文件不能碰，哪些命令不能执行，核心逻辑必须保持原样。

有了这些，系统持续运行稳定多了！

可就在你认为一切稳定之时，

致死时刻也在悄然来临！

致死时刻

数据库被agent删了，崩溃！

起因是，修改完一个需求之后，agent做了整体回归测试；

“哥们儿”太实在把清库、从零开始都测了！

是不是欲哭无泪！

估计到这里还会继续坚持使用的人已经不足30%了。

如何避免这类事故？

强制备份：在类似清空数据库这样的危险函数里，写死前置备份逻辑。配合定时任务，物理隔绝灾难。
环境隔离：测试库和生产库必须严格分离，绝不能在生成环境做有风险的测试。
二次确认：任何关键变更前，二次确认备份有效。

这些规则，也都可以通过Agent或程序固化下来。

幸好，我凭着多年习惯，提前手工做了备份，才得以逃生。

从那以后，儿子终于可以稳定地使用了。看着他用了整整三天，还说明天要分享给同学，我觉着这四个夜晚的煎熬，值了。

写在最后：AI是面双面镜，照出我们的焦虑，也照出未来的路

从启动到交付一个可单人使用的系统，我们只用了4天。这在传统软件项目中，可能连需求评审会都还没开完。这是AI令人窒息的效率。

但这4天里，我经历了从惊艳、失望、沮丧、甚至愤怒到想放弃的全部心路历程。这恰恰是当前每个AI使用者必经的“破茧”过程。

为什么我们如此容易失望？因为那些“一键生成”的童话，把我们每个人都惯成了甩手掌柜。我们错误地将AI想象成许愿神灯，而不是一辆需要学习驾驶的F1赛车。

要突破“想用又用不好”的困境，我们需要完成三重认知转变：

1. 从“使用者”到“指挥家”的心态转变。

你不是在给AI下命令，而是在指挥一个乐团。你无需会演奏所有乐器（写所有代码），但你必须懂乐谱（需求逻辑），有鉴赏力（审美与判断），能听出哪个声部走调了（发现bug），并给出清晰的指令。你用AI的上限，不取决于AI本身，而取决于你“指挥”的能力。

2. 从“对话”到“工程”的方法论转变。

偶尔的灵光一现可以靠“对话”，但要交付稳定可靠的系统，必须回归软件工程的根本，只不过这次，是人机协作的软件工程。

文档是契约：逼着AI写好的、更新的需求文档，是你俩之间唯一的、可追溯的合同。没有合同，所有故障都是糊涂账。

规范是护栏：红线、测试隔离、备份恢复机制，这些不是为了限制AI，恰恰是为了保护你和AI的协作成果，让创造力能安全落地。

流程是引擎：将经过验证的、固化的关键流程（如备份恢复、回归测试）写成脚本让AI执行，远胜过每次都口头吩咐。

3. 从“全有或全无”到“持续迭代”的耐心转变。

别指望一个通宵搞定完美系统。我的系统至今仍在迭代。接受“完成优于完美”的现实，接受过程中令人挠头的返工。每一次AI的“发疯”，都是你为他划定行为边界、为系统增加稳定性的机会。

截至现在，这个项目综合衡量下来，在开发效率和问题解决深度上，AI至少达到了中级程序员的水平，是我们前所未见的超级生产力。而驾驭这种生产力，将是我们这个时代每个人的必修课。

我仍在路上，探索如何让这套方法论达到高级程序员的水准，如何构建一套让Agent能稳定输出生产级系统的“法制”体系。这不是结束，甚至不是结束的开始，而恰恰是开始的结束。

AI时代，先别问要不要用。先沉下心，问自己会不会用。等你真正学会了和这个“毛躁的天才实习生”共事，你会发现，那个让你魂牵梦萦的“贤内助”，其实从未走远。

------

感谢阅读

真实经历，真诚分享

关注我，一个只分享 AI 实战记录的人类