Hi，我是 Chris。

熟悉我的朋友应该知道，我一直在开发一款本地优先的 AI 学习与知识工作台 WiseMindAI。

这个过程中，我越来越频繁地使用 CodeX，让它和我一起梳理需求、分析用户、设计界面、检查产品、整理文档，甚至把一份几十页的文档做成可以直接阅读的可视化页面。

今天这篇分享，是我前两天写完《写在 CodeX 和 ChatGPT 合并后的思考》后的一个想法，希望把自己的一些 CodeX 不错的经验分享给大家。

之前也写了一篇文章《CodeX 经验分享：每天 10 分钟掌握竞品、SEO 和宣传主题》，感兴趣可以回顾下。

今天分享 17 条我用 CodeX 开发 AI 应用的经验。即使你不会写代码，也能看懂并直接用起来。这些思路不局限于 CodeX，在 Claude Code 等工具上同样适用。

内容有点长，先一张图大致了解下：

一、先把事情想清楚

1.先理解你的想法

许多人一上来就说：“帮我做一个 AI 笔记产品”，但信息太少，CodeX 不知道你的产品给谁用，目前已经有什么，用户为什么需要这个功能。

我一般是会将自己的想法大致告知 CodeX，然后让它根据我的想法完善这个思路。列如同样是做一款 AI 笔记产品，我一般会问：

我想开发一个 AI 笔记产品，让用户可以在手机微信上随时保存文章，记录笔记，可以复习，你站在资深产品经理和市场经理角度来思考整个产品，给我一个详细方案。还要详细回答三个问题：这是什么产品？谁在使用？这次改动解决什么问题？

拿到方案后，我会仔细读一遍，跟 CodeX 对齐整个思路。

2.用任务清单描述需求

有许多小任务要一起改的时候，我会用有序列表把它们整理好，一次性发给 CodeX，逐一修改。这样后续可以直接用编号跟它对话，更准确，也不容易聊岔。

3.把大需求拆成小步骤

如果你说“帮我做一个完整的 AI 知识库”，它可能一次改许多地方。表面上看进度很快，出问题时却很难知道错在哪里。

我会先让它拆成：导入资料、解析内容、查找信息、生成回答、引用来源、保存结果。每一步都能单独运行，也能单独检查。

小步骤不等于慢。它只是让每一步都走得稳，最后一般反而更快。

4.提供多种方案

复杂问题一般没有唯一答案。我常常让 CodeX 给出三种做法：最快上线的、最适合长期发展的、改动最小的。

然后让它比较三种方案的优点、代价和后续影响，最后再给一个推荐。

这个习惯很重大。由于 AI 很擅长快速给出一个可行答案，但“能做”和“适合你”中间，还有很大的距离。

5.主动指出你没想到的问题

我会在任务最后加一句：“不要只执行我的方案，请指出其中不合理的地方、我忽略的用户情况，以及更好的做法。”

这句话等于允许 CodeX 提出异议。

我们对自己的想法往往很有信心，容易忽略新用户看不懂、旧数据不兼容、网络不好时无法使用等问题。我需要的不是一个只会说“好”的助手，而是一个会提前提醒我的搭档。

二、承担不同角色

6.从4个角度审查功能

我常用的4个角色是： 资深用户、产品经理、产品设计师和资深架构师。

• 资深用户关心产品能不能解决自己的需求
• 产品经理关心用户是不是真的需要
• 产品设计师关心用起来是不是顺手
• 架构师关心今天做完，性能如何，半年后还能不能改

这4个角度可能会相互冲突，但也正是这种冲突，才会让一个功能从“可以运行”变成“值得使用”。

列如下面让它站在资深用户角度去分析：

7.模拟第一次使用产品的小白用户

我们每天看自己的产品，许多操作已经成了本能。但新用户并不知道某个图标代表什么，也不知道应该先建知识库还是先上传文件。

我会让 CodeX 假设自己是第一次打开产品的用户，完成一个具体任务，记录每一个犹豫、不理解和容易点错的地方。

有时候，真正影响用户的并不是缺一个大功能，而是第一步根本不知道怎么用。

8.大白话页面文案

开发过程中很容易出现一些内部用语，列如“索引失败”“向量化异常”“请求超时”。这些话对做产品的人有用，对普通用户却没有协助。

用户真正需要知道的是：发生了什么，目前的内容丢没丢，接下来可以做什么。

我会让 CodeX 检查所有按钮、提示和错误信息，删掉只有制作者才懂的话，把每一句都写成用户下一步能采取行动的内容。

三、优先让产品好用

9.缩短用户操作路径

我常常会问 CodeX：“用户最少需要几步才能得到结果？”

列如文档总结，最短路径可以是选文件、点开始、看结果。至于模型、语言、详细程度和输出格式，都可以先给出合理默认值，放到高级选项里。

让用户做选择不必定是尊重用户。当选择过多时，更像是把产品应该做的判断丢给了用户。

10.CodeX 提出优化方案

当功能开发完成，我也会顺便问一下让 CodeX 看看还有什么要优化，优化完成后，自己使用浏览器等自行测试，最后提供一份优化清单和测试方案。

这让我发现许多没有思考到的地方。

当然，UI 界面也是一样，截图发给它，让它自己检查。

四、用架构思维设计产品

11.做有架构思维的产品

由于 Chris 本身是一位技术的架构师，因此在设计产品的技术方案，会思考一些常用架构方案，这也是让你的产品代码质量高、后期好维护的一个基础。

列如我会让 CodeX 站在资深架构师角度去分析需求，列出一些常用架构方案让它参考：

提前做好这些架构设计，对于整个产品超级重大，哪怕后面要手动排查问题，拓展产品功能，都超级有协助。

12.把重复的功能抽成公共模块

当产品中有些页面内容和功能高度类似，我会让 CodeX 判断：重复的是表面写法，还是背后的业务规则？只有那些真正一样、后来也会一起变化的部分，才值得抽出来封装成可复用的组件、工具方法或服务。

好的复用能减少维护成本，错误的复用则会把本来无关的东西捆在一起。

13.随时思考性能和拓展性问题

做架构很容走向两个极端：一种是今天能跑就行，一种是设想未来会有一百种变化，于是先做一个巨大而复杂的系统。

我给 CodeX 的原则是：对所有的需求都要思考性能方面的问题，避免后期功能堆积导致性能降低。

五、善用 CodeX 的长期记忆

14.把重大约定写进项目文档和记忆

如果你每次都要告知 CodeX：按钮应该用什么样式、文档要放哪里、修改旧功能要保持什么规则，那说明这些知识还只在你的脑子里。

我会把稳定的产品原则、界面规范、文档规则和验收要求写进项目文档，让 CodeX 每次开始前先阅读。

这些文档就像一份长期产品开发手册。它不但协助 CodeX 保持一致，也会迫使我们把产品中那些“只可意会”的经验真正说清楚。

15.功能分析文档随时保存

在重大需求开发前，让 CodeX 完整分析需求，并沉淀一个文档下来，好处超级多，列如：

1. 设置为记忆，让 CodeX 对项目功能、细节等更清楚
2. 沉淀产品知识库，不管后面做产品官网，问答机器人的知识库还是让 CodeX 写宣传文案等等，都超级方便

好处有许多的。

另外，功能有调整的时候，也顺便叫它同步更新对应文档。

下面是 WiseMindAI 项目沉淀的知识库内容，有许多：

六、交付可用的结果

16.让 CodeX 沉淀开发经验

一次开发中解决的问题，如果只留在当次对话里，下次很可能还要再遇到一次。

所以每次完成一个较大功能后，我会让 CodeX 回答四个问题：这次做了什么？遇到了什么问题？最后采用了什么规则？哪些经验应该写进长期文档？

17.把长文档做成可视化页面

这是我超级喜爱的一个用法。

一份竞品报告、用户调研或项目规划，用 Markdown 保存很合适，但并不必定适合阅读。我会让 CodeX 在保留原始文档的同时，再生成一份可视化 HTML 报告。

重点不是页面多好看，而是重新设计信息的阅读方式：关键数字放在最前面，变化趋势用图表，产品对比用表格，复杂关系用流程图，结论和行动提议单独突出。

这样既有可以长期存档的完整文档，也有可以在 10 分钟内快速看懂的阅读页面。

当然，还可以让它直接按照需求以 HTML 页面形式生成页面 UI 效果图：

写在最后

用好 CodeX，关键在于你能不能先把问题想清楚，能不能从用户的结果出发，能不能用清晰的规则让产品长期保持稳定。

我们所以除了问“CodeX 还能帮我写什么”，更值得多问一句：“我要怎么和 CodeX 合作，才能为用户做出更好的东西？”。

这才是 AI 应用开发真正有意思的地方，当然，其他软件也可以这样的思路去使用。

好了，今天就分享到这里，我们下一期再见。