基本信息

来源摘要/节选

公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。

昨天同事在用 Codex 写一个新模块。从上午到中午，提示词改了好几轮，代码生成了一版又一版，结果始终不是他想要的。 “算了，我还是自己写吧。” 我问他：“要不先别急，你跟我说说这个模块要干嘛？” 问题出在哪 聊完发现问题其实挺简单：他没把需求想清楚，就开始让 AI 写代码了。 很多人用 AI 是这样一个循环：有个模糊想法 → 直接丢给 AI → 看生成结果 → 不满意改提示词 → 再来一轮。几轮之后人就开始烦躁，最后得出一个结论：“AI 不行。” 但很多时候问题不是 AI，是需求本身模糊。 AI 和人的区别在这 人写代码的时候，能容忍很多模糊信息。因为你会自动补全上下文——结合项目背景、参考已有代码、凭经验推断逻辑。 AI 不一样。它是严格依赖你给的信息的。 如果输入是不完整的、没结构的、想到哪说到哪的，它只能自己补。 而 AI 补出来的东西，往往是行业通用方案、常见架构模式——它训练数据里最多的那些。 所以会出现一个现象：AI 写的代码"看起来很合理"，但就是不符合你的需求。 不是 AI 写错了，是你没告诉它真正的需求。 我让他先别写代码 聊清楚之后，我让他暂停和 AI 对话，先做一件事：驱动AI把需求结构化。 我们一起花了大概二十分钟，把整个模块拆开： 这个模块解决什么问题？ 在系统里处于什么位置？ 输入输出是什么？ 需要遵守什么规则？ 一点一点驱动AI生成完整的需求文档，很多人会觉得这一步"很慢"，但磨刀不误砍柴工。 不要急着让 AI 写代码 然后我建议他：先让 AI 帮你写"大纲"，而不是代码。 提示词大概是这样：根据现有代码结构和需求概览，生成模块设计大纲。 AI 很擅长做这件事，本质上是结构化信息生成。 很快我们就得到一个模块结构：模块职责、核心流程、子模块划分、数据结构、异常处理策略。相当于 AI 帮你写了份设计文档。 接下来就很舒服了：完善需求。…

来源说明

当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。

本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。