今天我们来讲讲如何使用AI写代码，你可能会想这有什么好讲呢？装个Codex或者是Claude Code，直接向AI发条指令不就行了吗？给我做个笔记软件、给我做个剪辑软件、给我做个电子书阅读器，这不是太简单了吗？还要你来教。我相信你给AI一个指令，它确实可以帮你把软件做出来，但我的疑问是：AI做出来的效果真的跟你预期的一样吗？有没有可能你脑子里面想的是一个东西，AI最后交付的却完全是另外一个东西呢？更不用说有些时候AI做出来的产品还有很多bug，跟自己想象的效果实在是相差甚远。相信你多多少少都会遇到过这种情况吧？那该怎么解决呢？这个就是我这期视频想聊的问题：怎么才能够让AI交付一个真正让你满意的作品。

接下来我会带你从头做一个电子书阅读器，你会发现这不是给AI发条指令就完事了，中间要经历好几个步骤。我不仅会带你把流程完整走一遍，还会告诉你每一步到底解决了什么问题、哪些环节可以省、哪些环节最好不要省。理解了这些，你就能把它调整成适合自己的AI工作流。好话不多说，让我们赶快开始吧！

首先我们需要选择一款适合自己的编程Agent，目前主流的选项有Codex和Claude Code，此外还有OpenCode、Pi Cursor等等。如果你没有特殊要求的话，建议直接选择Codex，它的功能相对来说比较完善，几乎没有明显的短板。作为OpenAI旗下的产品，你可以通过订阅ChatGPT在Codex里面调用GPT模型；如果不方便订阅的话，也可以将DeepSeek、GLM、Kimi等国产模型接入进来。Codex算是一个通用的编程Agent，它并不跟GPT模型强绑定，实际上大部分模型都能跟Codex配合使用。

我之前发布过两期视频分别介绍了Codex的基础用法以及如何接入国产的模型，感兴趣的朋友可以去了解一下。我发布的时间比较早，当时Codex的界面跟现在稍微有些区别，不过里面的功能都没有什么大的变化，所以不必担心。后续的内容以Codex为例演示如何用AI实现你想做的产品。顺便提一句，虽然演示用的是Codex，但我会尽量避免使用它独有的功能，这里设计的核心操作逻辑呢都是通用的，你用Claude Code、Pi或者说是其他的Agent同样可以完成。挑选好了编程Agent之后，下一步我们要做的就是环境搭建。

环境搭建的第一步就是给我们的产品创建一个对应的文件夹专门存放项目代码，我这里要做的是电子书阅读器，我们就给这个电子书阅读器起个名字叫做“马克阅读”吧。那下面我们就来创建一个对应的文件夹。好，文件夹创建好了。然后我们打开Codex点击这里面的加号创建一个新的项目，项目类型我们就维持本地就好了。然后点击下一步，下面我们把刚才创建好的这个叫做“马克阅读”的文件夹给加入进来，然后点击创建项目。好这样呢项目就创建好了。然后呢我们来让Codex把当前的目录初始化为一个Git仓库，我们的指令很简单就是帮我把当前的目录初始化为一个Git仓库。

然后我们提交好Codex开始干活了，在他干活的间隙我来给不了解Git的小伙伴稍微解释一下Git到底是什么。简单来说Git就是一个版本管理工具，我们每做完一个新功能就可以使用Git把它保存为一个对应的版本。这样即使哪天代码被搞乱了，也能够一键回退到之前的可用状态，非常的高效也非常的好用。实际上我建议你所有的代码项目都拿Git来管理，甚至可以考虑把代码推送到GitHub上。这样即使本地代码丢了我们也能从GitHub上面把代码拉下来，防止之前的劳动成果付诸东流。

不过我们这里呢就不演示GitHub的使用了否则视频会有些冗长，我们就演示下Git的使用。不了解Git或者是GitHub的小伙伴呢可以自己去找相关材料看一下。好Codex做完了，我们打开终端来验证一下：首先进入到这个“马克阅读”的文件夹里面然后执行git status命令，可以看到正常返回了也没有报错。这就代表当前目录确实已经被Git托管了。下面呢我们回到Codex这里然后再让它添加一个新的文件，我们的指令是创建一个AGENTS.md文件写入下面这些内容最后提交一个commit。

然后呢我们把文件内容也贴进来后呢我们提交这个指令，下面我来给大家解释一下刚才我是在干什么？对吗？我们刚才让Codex创建了一个叫做AGENTS.md的文件。AGENTS.md呢就相当于是给Codex写的项目说明书，每次你开启一轮新的会话优先的读取里面的内容从而快速了解当前的项目背景和开发规范。这里面呢我们是告诉Codex必须要遵守两个规定：第一个呢是每次改动之后都必须要创建一个对应的git commit，以便后续继续追踪和回滚。

你可以大致理解为Codex每完成一个功能都要顺手帮我们保存一个版本快照，这样后面如果哪一步改出了问题我们就可以非常方便的找到之前正常的版本直接退回去不用担心代码越改越乱。我们的第二点要求是每次改动之后都必须要编写或者是更新相关的测试，并在交付给用户前确保所有的测试和验收全部通过。这个要求呢很好理解啊：我们不希望Codex写完代码之后呢就直接交差，而是希望他自己先跑一遍测一遍。发现问题呢就继续修一修直到他能够确认当前的改动基本没有问题了再来告诉我们完成了。

这样的话呢就可以提前帮我们挡掉不少比较明显的bug节省我们的时间。好看起来呢Codex已经创建好AGENTS.md文件了，我们可以回到那边看一下：可以看到文件确实是创建好了内容也跟我们要求的是一模一样的。那到这里为止我们的环境就算是搭建完了，其实总结下来也就两件事情：一个是Git另外一个是AGENTS.md。接下来呢我们就可以正式进入到产品设计环节了。

我们现在知道自己要做一个电子书阅读器，但是具体要做成什么样子其实大家心里可能都还没有一个非常确切的答案。在这种情况下我一般会先跟AI讨论一下产品的设计，比如我们可以写这么一段要求：“我想做一个电子书阅读器打算先从MVP版本开始你觉得这一版做哪些功能比较合适呢？”有些小伙伴可能会问MVP是什么？简单来说MVP就是minimal viable product的缩写，中文呢一般是叫做最小可用产品。

简单来说就是第一版只做最核心最必要的功能先把产品的主流程跑通，其他功能以后可以慢慢加。这样做的好处是可以用比较低的成本快速验证产品方向：你想啊如果一开始的时候就把功能铺得太大，后面发现方向不对的话很多工作可能就白做了。所以呢我们先把电子书阅读器最基本的体验做出来确定没问题后再逐步往上加功能。好让我们把指令发出去看看AI会给我们什么回复？

AI回答完了我们来仔细看一下，他先提到了要支持导入本地的EPUB文件。EPUB呢是一个非常常见的电子书格式，支持这种格式呢是没有什么问题的。不过我觉得这个格式呢可能还是稍微有一些复杂度：既然要做最小可用版本，那我希望一开始要做的功能就越简单越好。比如我们一开始就支持导入TXT文本文件：我们可以直接在下面的输入框里面输入我们的想法：“我觉得EPUB也稍微有些复杂了，我们一开始是不是可以只支持最简单的TXT文本文件呢？”好这个时候呢不要着急提交。

因为我们还没有看完整个回答，让我们继续看：有问题直接追加到输入框里面最后一起提交。他这里提到了关于目录和章节的相关功能，如果我们只支持TXT文本文件的话那基本上也就没有什么目录和章节可言了。纯文本文件哪来的什么目录和章节呢？即使有的话那也不是能够通过固定方法解析到的。所以呢我们也可以把这部分功能去掉：让我们把这部分想法追加到输入框里面，“如果只做TXT的话那也就没有什么目录和章节可言了，毕竟TXT没有目录和章节的概念，那这些也不用”。好继续往下看。

这里还提到了要同时支持明亮、护眼、深色三种主题，我们一开始不用支持这么多就先做明亮主题就好了。让我们追加到输入框里面：“只做明亮主题就行，护眼和深色可以先不做。”你看这里还提到了书签：书签呢其实我们也不需要因为他们不是必要功能。所以呢我们再追加一句：“书签也可以先不做。”好后面应该没什么了吧？就这些了。我们再追加一句：“总之我们先做最基本的功能，其余的功能后面再迭代。”你觉得前面这些想法有没有什么问题呢？我们来提交。

Codex说我们的思路没有什么大问题，不过提到了几个要注意的点：一个呢是文件编码他建议我们第一版仅支持UTF-8就行；第二个呢是阅读方式第一版只支持纵向滚动先不做分页；然后呢还有载入大文件需要给出一些提示。最后呢它还给出了可以推迟的功能列表，可以的这些我都赞同。到这里其实我们对第一版要做什么、暂时不做什么已经有了一个比较明确的共识，接下来呢我们最好把这些内容整理成一份产品设计文档把它当成后续开发的一个底稿。

这样无论后面是做技术方案还是让AI写代码大家都有一个统一的依据：简单来说这份文档就是先把MVP的边界给定下来。让我们给AI发一条指令：“我同意你的建议，接下来帮我整理一份产品设计文档吧。”不用太详细把整体方向和主要功能梳理出来就可以。大家注意我的措辞啊，我明确告诉Codex不用太详细否则字太多了我们看起来也累差不多就行了。我们只需要保证大体方向跟我们想的一致就行，如果真的有什么细节跟我们预期的不太一样那后面再迭代就好了。我觉得这样更方便一些：接下来我们提交。

好Codex写完了我们来大体看一下，好像是没什么问题那就这样吧！到这里我们这个产品的设计方案基本上就已经确认了。不过有些时候在产品设计的最后我还会再多做一个环节那就是让AI画一个demo。所谓demo你可以把它理解成一个可以实际操作的前端页面，这里说的前端就是指我们看得见点得到的界面。与前端相对应的词是后端它指的是背后真正处理数据执行功能的那些逻辑。

做demo的时候我们通常只会把前端做出来后端暂时不实现里面的数据一般都是直接模拟的。比如我这里准备了个人知识库的demo给大家看一下，它跟我们现在正在做的电子书阅读器没什么关系我就是用这个文件来给大家解释一下一个demo大概是长什么样子的。大家可以看到它其实就是一个HTML文件我们直接把它打开就行了：打开之后你可以看到左边是文档列表，中间的系统给出了一些推荐问题。我们点击一个推荐问题它就开始回答了；回答完毕之后点击引用文件右边就会展示回答所有引用的原文。

大家注意啊这里面只有前台页面是真的：这个回答和相关的这些知识库文件呢其实都是模拟的因为后端逻辑还没有实现。这个页面仅仅是包含前端逻辑它的主要目的就是为了让用户体验一下整个界面的交互和操作流程到底顺不顺手。如果哪里感觉不对就可以继续让AI修改这个demo直到整体体验比较符合我们的预期为止。我觉得吧做这种demo有两个好处：第一个好处是它可以让我们提前验证一下产品设计，很多东西光靠文字其实很难想象真正把页面画出来亲自操作一下之后你可能就会发现一些之前没有想到的问题。

如果发现设计不合理我们可以继续修改demo同时把对应的产品设计文档一起调整一下；第二个好处是它可以让后面的产品实现更加精确：你想demo可以非常直观的告诉AI我最终想要的产品大概就是这个样子，这个呢是文字描述很难做到的。后面真正实现的时候呢我们就可以把产品设计文档和这个demo一起交给AI，这样AI既知道要做哪些功能也知道界面和交互应该怎么还原。最后做出来的东西一般会更加接近我们的预期：当然并不是所有项目都有必要做demo，那到底什么时候适合做demo呢？

我一般会看一个非常简单的因素那就是这个产品的后端实现成本。像刚才的这个个人知识库后端实现的成本还是挺高的因为这里面会涉及到文档处理、搜索检索策略、模型调用等等很多的后端逻辑。在这种情况下我更愿意先做一个demo把界面和交互确定下来；但我们现在要做的这个电子书阅读器就不一样了，它的后端实现成本就很低了：毕竟就是一个看书软件嘛导入TXT文件就可以了没有什么太复杂的逻辑。这个时候如果还专门做一遍demo可能反而有些重复劳动还不如直接把产品给做出来等真正跑起来之后哪里不顺手我们直接在完整的产品上面继续调整就可以了。

那如果说你觉得自己的项目有必要做一个demo的话具体该怎么跟AI说呢？其实指令很简单，比如可以这样：“帮我做一个demo不用实现真实的后端功能数据模拟一下就行。我主要是想看看整体界面和操作流程是否合理。”对就这么简单：后面如果你觉得哪里不满意就继续让AI修改直到整体效果符合你的预期就可以了。不过就像前面所说的我们这个电子书阅读器比较简单没有太大必要专门做一遍demo，所以呢这里我也就不发这条指令了。大家在自己的项目里面可以根据实际情况决定要不要加这一步：好到这里产品设计就正式结束了，下面我们来设计对应的技术方案。

我们可以直接在当前这个会话后面继续追问技术方案相关的内容也可以创建一个新的会话来做这件事情，这两种方式都是可以的。有些小伙伴可能会想：如果在当前会话继续追问的话上下文越积越多对大模型的效果可能就会有一定程度的影响。确实有这种可能性，不过根据我个人的使用体感现在的顶级模型对于长上下文的驾驭能力是越来越强了再加上对应的上下文压缩机制正常使用的话一般不用过于担心上下文的问题。我甚至经常在一个会话里面连续跑几个小时都没有感觉到有什么太大的问题：不过为了稳妥一点也为了让后面的技术方案讨论更为聚焦我们这里还是新开一个会话专门来做技术方案的设计。

这里我们还是照样先跟AI讨论一下可能的技术设计方向让他给一些建议：你可能会听说Electron非常适合做这件事情只是你对Electron没有那么熟拿不定主意。这个时候你就可以把你的想法跟AI说一下让他帮你看看Electron合不合适：我们这么发指令，“在这个目录下面有一份产品设计文档请你读一遍这个产品设计文档然后告诉我用什么技术栈设计这个产品比较合适。不用给出过于详细的设计我们就先探讨一下，我听说Electron还可以你怎么看呢？”

好Codex回答完了他说Electron非常合适，它会优先采用还给出了建议的技术栈。同时呢也给出了Electron的缺点以及另外一个可能的选项就是Tauri，最后呢他总结了一下说是可以用Electron加React再加上TypeScript还有Vite还有Electron Forge这套架构。看起来好像没有什么问题啊：还是跟之前一样我们来让AI出一个技术方案文档这样后面具体写代码的时候呢就可以以这个文档作为参考。我们来发条指令：“行就按你说的来，现在请你写一个技术方案放在docs文件夹里面。”

Codex写完了我们大体看一下好像还行的样子那就这样吧！说实话我也不是特别懂这块只要是保证大体方向没问题就行。到这里技术方案的设计就算是完成了，下一步就是真的要编写代码来实现了：在正式编写代码之前我先提一句我们最好让AI拥有自行验证结果的能力。如果你用的是Codex那我建议至少安装两个插件：我来给大家看一下，第一个是叫做computer use它可以用来操作电脑；第二个呢是叫做Chrome它可以用来查看Chrome页面。有了这两个插件大部分的功能都是可以交给AI来验证的包括我们现在做的这个电子书阅读器也是同样的道理。

如果你用的是别的编程Agent那可以自行查证对应的插件或者是skill给AI一个能够验证的环境是一个非常重要的事情否则AI很容易就会写出一堆bug毕竟他没法验证嘛：如果人写代码没法验证的话那估计也会有一堆bug。好这里呢我已经安装了computer use和Chrome这两个插件，那Codex应该已经具备了验证功能完备性的能力了。下面我们就来新建一个会话让Codex帮我们实现这个产品，让我们发条指令。

我们的指令是这样的：这个目录下面有两个文档，一个是产品设计，一个是对应的技术方案。请你读一下这些文档，然后根据里面的要求实现这个产品提交。接下来我们稍微等一下，写代码估计要花不少时间。好终于写完了！可以看到他不仅把产品做完了，还完成了各种自测，确保他写的代码没有问题。这符合我们在AGENTS.md里面的要求：“你是不是都忘了？我们在AGENTS.md写了什么了？”没关系我再给你看一下，就是这里面的第二条：每次改动后都必须要编写或者更新相关的测试，并在交付给用户前确保所有的测试和验证全部通过。

对我们明确要求Codex写完就要测试，不过话说回来这些测试呢只能尽可能提高代码的可靠性帮AI提前发现一些明显的问题并不能够保证最终交付出来的产品就一定没有bug。真正用起来再怎么样还是得我们自己亲自验证之后才知道，所以接下来我们就来实际跑一遍来看看。嗯他最后提到执行npm start的命令就可以启动那我们这就来试试，似乎上来就报了一个错。你看AI确实不是百分之百靠谱的即使他自己能验证也未必完全可靠，我们让Codex修一下。

我们发出的指令是这样子的：打开之后呢直接显示了一个报错“操作失败请稍后重试”，然后我们提交让Codex修一下。好Codex修好了，我们再试试可以了错误消失了！我们导入一本TXT文件试试看起来好像还可以的样子。好到这里这个产品的MVP就算是彻底做完了，我们的第一个需求就彻底做完了！

我们简单回顾一下刚才的整体流程一共是分为五步：第一步环境搭建，比如说是初始化Git版本控制、写一个基本的AGENTS.md等等；第二个产品设计这一步呢主要是明确要做什么不做什么，这里我们会跟AI探讨产品方案并在某些情况下出一份demo；第三个技术设计这一块主要是确定技术方案，尤其是技术栈和架构以便确保整体方向没有问题、设计符合我们的要求。

第四步产品实现在这个环节里面我们不仅让AI实现代码还要给AI自测的能力，让他写完代码之后能够自己测试把明显的问题全部修掉。这一般需要我们安装类似computer use或者是Chrome的插件；第五步人工验证这一步主要是我们亲自上手体验，发现问题就让AI修改一直到完全符合预期为止。你看这里面除了第一步环境搭建是一次性的我们开发每一个新功能时的标准流程，比如说后续你想给阅读器加一个全文搜索功能同样也是这个流程。

我们需要先做产品设计确定搜索入口该放在哪里、结果该怎么展示然后再出技术方案这一步主要是确定文本怎么索引、最终的搜索是怎么实现。接着呢我们让AI完成开发和自测然后我们再亲自验证当然这几个步骤并不是死板的流程具体要做到什么程度取决于你想对最终结果保留多少掌控力。比如如果你并不在意产品具体该怎么设计只要功能能用就行那产品设计这一步我们就可以完全不用管交给AI就行了。

如果你也不关心代码具体怎么实现技术方案呢同样也可以不用关心让AI自己决定这么做呢其实并没有什么太大问题只是意味着你把更多的决策权交给了AI这样的话你对最终结果的掌控自然就会少一些做出来的东西呢可能也就没有那么贴合你的预期。所以这里面其实就是一种取舍你参与的越多对最终结果的把控就会越强但需要投入的时间和精力也就越多；你参与的越少开发过程会更省事更快但最终结果和你预期之间出现偏差的可能性也会越高。

这个度其实没有一个特别固定的标准我一般会根据需求的复杂度和重要性来判断比如我们可以用两种情况来举例：一种是简单且不重要的需求；另外一种是复杂且重要的需求。对于第一种情况我一般会忽略产品设计和技术设计这两个环节搭好环境发出指令之后我会直接让AI实现，实现完后我做验证验证完了之后这个需求就结束了整个流程会非常快。

但如果是复杂而且重要的需求我则会参与到产品设计和技术设计的环节中来走完这完整的五个环节尽可能的保证最终产品的质量。所以这里并没有一个固定的标准说到底还是在开发效率和结果的可控性之间做取舍不过话说回来尽管流程可以根据需求灵活调整但有三个原则我建议大家尽量坚持。

第一必须有版本管理工具比如你可以用最流行的Git来管理代码AI写代码呢不可能每次都完全正确有时候甚至会在修改的过程中把原本能够正常运行的功能改坏了。用了Git之后我们每完成一个功能都可以保存一个对应的版本后面一旦出了问题就能很方便的恢复到之前正常的状态。另外如果条件允许的话我也建议把代码同步到GitHub之类的远端仓库是本地代码不小心丢了也能够从远端恢复。

第二点我们必须要给AI自测的能力很多人只是让AI写代码但不给他验证的环境结果自己就沦为了测试员来来回回帮AI找bug极其浪费时间。我们应该把相关的工具和插件开放给AI让他自己写完自己测这样交付出来的代码质量就会高很多；第三必须要进行人工验证也不可能把所有的问题都覆盖到像交互体验或者是一些不容易想到的边界情况就很容易被漏掉。

所以产品到底好不好用是不是我们真正想要的最终还是要自己试一遍才知道总结一下真正不能省的就是这三件事情：用Git搭建好环境、让AI具备自测能力最后还一定要人工验证。至于这里面的产品设计和技术设计要做多细大家看情况决定就好！

最后我想说这套流程只是我现阶段探索出来的比较合理的方法但并不是唯一的标准答案。随着大模型能力的不断进化AI编程的模式肯定还会发生变化我也会持续去尝试其他可行的方案。如果大家有什么更好的想法欢迎在评论区里面留言我们一起交流进步！好了今天的视频就到这里了我是马克我们下期再见拜拜