ARTICLE · 1163493
我用AI做了一个公司资源管理软件(三):我是怎么指挥 AI 写代码的
很多人以为，用 AI 写软件，就是一句话："帮我做个系统。"
但真正用下来我发现，关键不是让 AI 一次性写完，而是你要会指挥它。
更准确地说——是你要把业务判断说清楚。
我不是一次性写完整需求
这个系统不是从一份完美的需求文档开始的。
它更像一场连续对话：我看到哪里不对，就直接说出来。
比如：
"你没有让我有地方新增项目啊。"
"人员信息加一个编辑功能。"
"资源看板增加按项目过滤。"
"周六周日默认休息。"
"手动调整安排里，不要一删删掉整个周期。"
这些话听起来不像专业的需求文档，但它们很真实。
AI 能理解这种业务语言，并把它翻译成代码修改。
指令越具体，效果越好
我一开始也会说得比较笼统，比如："优化一下老板看板。"
AI 会照做，但结果不一定符合我心里的场景。
后来我发现，只要把使用场景说出来，效果就会明显变好。
比如我会这样说：
老板的使用场景可能是这样的：需求方告诉他，我某月哪几天需要几个前端、几个测试、几个产品；然后老板能通过这个看板，看到客户说的那个时间，是否有资源可以安排。
这一句，就比"优化老板看板"清楚得多。
AI 不是读心术，它需要场景。
场景清楚了，它才判断得出界面该怎么组织、数据该怎么算。
我不断纠正它
AI 写出来的东西，不会每次都对。
有时候它会理解错。比如我说"手动调整安排要列出每一天"，它一开始给每一天都加了"新增口子"。
但我真正想要的是：周末和法定节假日也列出来，只是默认小时是 0，我可以按需要改。
于是我继续说：
不是每天都加一个新增口子。是周末或者法定节假日那个字段跟其他字段不要变，就列出来，然后把小时改成 0。
这种纠正很重要——你不能期待 AI 第一次就完全理解复杂业务。
它更像一个反应很快的开发搭档：你指出问题，它马上改。
我会用真实案例去检查
系统不是"看起来对"就行。
我会拿真实人名、真实日期去测，比如：
少堡主 6 月 20 日是有安排的，怎么显示在 6 月 27 日超负荷？
这类问题一出现，就说明日期计算可能有 bug。
再比如：
J 工是超负荷的，我打开资源日历，手动调整弹窗显示成喵工了。
这说明弹窗的默认人员选择逻辑错了。
真实案例，比抽象描述更容易定位问题。
而且——AI 也更容易根据具体的日期、具体的人、具体的页面，去查原因。
我会区分"要改"和"要提交"
用久了，我慢慢形成一个习惯：有些修改只是试试看，有些修改确认后才提交到 Git。
比如视觉美化，我让 AI 做过一版很花哨的效果；后来判断暂时不需要，就要求它把这部分代码去掉。
这点很重要。
AI 开发速度很快，但越快，越要有版本意识——不是每一次尝试，都应该进入正式版本。
我学到的协作方式
这次最大的经验是：不要把 AI 当成一个"万能按钮"，要把它当成一个非常快的开发搭档。
分工其实很清楚。
我负责判断：
这个功能是不是业务需要
这个逻辑是否符合管理场景
这个页面是不是好用
这次改动要不要提交
AI 负责执行：
查代码、改代码
跑检查、总结改动
打包文件、说明发布分支
当双方分工清楚，效率会非常高。
写在最后
用 AI 写系统，最重要的能力，不是会不会写代码，而是会不会表达问题。
你越能描述清楚真实的业务场景，AI 就越能帮你做出接近可用的软件。
下一篇，我会写这个系统里最核心的部分：资源申请、审批和资源日历，是怎么一步步做出来的。
如果你也在用 AI 解决工作中的"破表格搞不定的事"，欢迎关注，我们下一篇接着聊。
📌 系列回顾