即刻App年轻人的同好社区
下载
日常写作，我会高频用到几个提示词。
今天想把我日常写作和阅读资料的提示词分享给大家，都是我过去两年慢慢积累和调整出来的。
我想说，很多场景中，提示词依然重要，依然重要。
和 AI 用不同的方法沟通，最后可能返回的结果完全不一样。
我之前写过自己的写作流程。简单来说，就是先用语音输入法把脑子里的想法口喷出来，不管结构，也不管口头禅，先把意思说完整。
然后再让 AI 根据我的文风，把这些比较乱的口语整理成初稿。
接下来，我会静下来，逐字逐句的修改。这中间，也会让 AI 参与。下面这些，就是我平时使用频率最高的提示词。
1）阅读资料
如果读的是一篇论文，或者技术类的讨论，可以这么说：
详细总结下这个论文（也可以是产品）解决了什么问题，思路是什么？有什么非共识的判断。
如果是一个随性的播客：
详细总结下这个播客的主线是在讨论什么？有什么非共识的判断吗？
2）整理语音底稿
假定你是我的资深编辑。这是我打的语音底稿，你不用大改，只需要把错别字改掉，没有捋顺的逻辑改掉，把特别口水的内容改掉，让它成为一篇逻辑顺畅但是符合我文风没有 AI 味道的文章。
该补充的地方补充，保证交给我的是可读的。MD 的内容供你参考。
当然，我也希望你能深度思考。看看我的表达哪里不准确。所以，确定的步骤是这样。
第一，你先理解语音底稿，和附件的信息，形成自己的理解和判断。
第二，你再在我的语音底稿的基础上开始修改和优化。但注意，整体的表达要用我的风格，不用改节奏和风格。
第三，不要刻意的使用排比句，不要使用一个字的动词。
第四，不懂的地方问我。不要硬凑句子。
有时候，我用语音输入法口喷完后，发现自己其实思路也没特别想清楚。这时候，可以和 AI 讨论。提示词是：
你读完这份语音底稿和 MD 内容后，告诉我：这篇文章真正想表达的核心判断是什么？只能说一个。
如果里面同时存在几个观点，也请告诉我哪个最值得作为主线，其他观点应该放在什么位置。
或者再进一步：
请站在一个长期关注 AI 的读者角度，检查我的语音底稿。看看哪些内容只是大家已经知道的常识？哪些内容真正提供了新的信息、判断或者观察？
3）修改稿件
有时候，总感觉某几句话说的稀里糊涂，总觉得没到位，这时候我会说：
你看看这句话是不是没说透？咱们深度讨论下。
再或者还有的情况下，我确实卡住没思路了。这种情况下，可以用这个提示词：
我实在没思路了。你看看如果继续线性推进我的观点的话，你会怎么写？不要着急续写，先给我你的思路。
如果有时候需要个例子，但自己没有想法，可以这么说：
帮我想一个锚点类比。好的类比是读者生活中熟悉的事物，同时能够准确刚刚的概念。
4）请 AI 提反馈建议
上面是我写的文章。不需要拍我马屁，作为一个资深的作者，你觉得这篇文章还有哪些地方可以优化？
或者有时候，担心自己的文章写的不准确。这时候可以用：
不要顺着我的观点说。请站在反方，找出这篇文章最容易被质疑的三个地方。
哪些判断证据不足？哪些推论跨得太远？哪些地方可能存在另一种解释？
再或者写完之后，我发现一篇文章信息很多，单段很好，但文章结构可以调整。
可以用：
先不要改句子，只检查文章结构。每一部分分别在解决什么问题？目前的顺序是否合理？哪些内容应该提前，哪些内容可以合并，哪些内容会打断阅读节奏？
还有的还是，感觉开头不好，可以试试：
这篇文章的开头有点慢。请从我文章中已有的经历、细节或者反常识判断里，找一个更自然的开头。
不要上来总结背景，不要先讲大道理，也不要虚构场景。
上面这些提示词我都没有做成 Skill。有一些常用的，我直接放到了苹果电脑的备忘录，打开就能用。
另外一些不常用或者简短的，基本上我就记在了脑海，其实只要记思路就行，和 AI 沟通的思路。
今天想把我日常写作和阅读资料的提示词分享给大家，都是我过去两年慢慢积累和调整出来的。
我想说，很多场景中，提示词依然重要，依然重要。
和 AI 用不同的方法沟通，最后可能返回的结果完全不一样。
我之前写过自己的写作流程。简单来说，就是先用语音输入法把脑子里的想法口喷出来，不管结构，也不管口头禅，先把意思说完整。
然后再让 AI 根据我的文风，把这些比较乱的口语整理成初稿。
接下来，我会静下来，逐字逐句的修改。这中间，也会让 AI 参与。下面这些，就是我平时使用频率最高的提示词。
1）阅读资料
如果读的是一篇论文，或者技术类的讨论，可以这么说：
详细总结下这个论文（也可以是产品）解决了什么问题，思路是什么？有什么非共识的判断。
如果是一个随性的播客：
详细总结下这个播客的主线是在讨论什么？有什么非共识的判断吗？
2）整理语音底稿
假定你是我的资深编辑。这是我打的语音底稿，你不用大改，只需要把错别字改掉，没有捋顺的逻辑改掉，把特别口水的内容改掉，让它成为一篇逻辑顺畅但是符合我文风没有 AI 味道的文章。
该补充的地方补充，保证交给我的是可读的。MD 的内容供你参考。
当然，我也希望你能深度思考。看看我的表达哪里不准确。所以，确定的步骤是这样。
第一，你先理解语音底稿，和附件的信息，形成自己的理解和判断。
第二，你再在我的语音底稿的基础上开始修改和优化。但注意，整体的表达要用我的风格，不用改节奏和风格。
第三，不要刻意的使用排比句，不要使用一个字的动词。
第四，不懂的地方问我。不要硬凑句子。
有时候，我用语音输入法口喷完后，发现自己其实思路也没特别想清楚。这时候，可以和 AI 讨论。提示词是：
你读完这份语音底稿和 MD 内容后，告诉我：这篇文章真正想表达的核心判断是什么？只能说一个。
如果里面同时存在几个观点，也请告诉我哪个最值得作为主线，其他观点应该放在什么位置。
或者再进一步：
请站在一个长期关注 AI 的读者角度，检查我的语音底稿。看看哪些内容只是大家已经知道的常识？哪些内容真正提供了新的信息、判断或者观察？
3）修改稿件
有时候，总感觉某几句话说的稀里糊涂，总觉得没到位，这时候我会说：
你看看这句话是不是没说透？咱们深度讨论下。
再或者还有的情况下，我确实卡住没思路了。这种情况下，可以用这个提示词：
我实在没思路了。你看看如果继续线性推进我的观点的话，你会怎么写？不要着急续写，先给我你的思路。
如果有时候需要个例子，但自己没有想法，可以这么说：
帮我想一个锚点类比。好的类比是读者生活中熟悉的事物，同时能够准确刚刚的概念。
4）请 AI 提反馈建议
上面是我写的文章。不需要拍我马屁，作为一个资深的作者，你觉得这篇文章还有哪些地方可以优化？
或者有时候，担心自己的文章写的不准确。这时候可以用：
不要顺着我的观点说。请站在反方，找出这篇文章最容易被质疑的三个地方。
哪些判断证据不足？哪些推论跨得太远？哪些地方可能存在另一种解释？
再或者写完之后，我发现一篇文章信息很多，单段很好，但文章结构可以调整。
可以用：
先不要改句子，只检查文章结构。每一部分分别在解决什么问题？目前的顺序是否合理？哪些内容应该提前，哪些内容可以合并，哪些内容会打断阅读节奏？
还有的还是，感觉开头不好，可以试试：
这篇文章的开头有点慢。请从我文章中已有的经历、细节或者反常识判断里，找一个更自然的开头。
不要上来总结背景，不要先讲大道理，也不要虚构场景。
上面这些提示词我都没有做成 Skill。有一些常用的，我直接放到了苹果电脑的备忘录，打开就能用。
另外一些不常用或者简短的，基本上我就记在了脑海，其实只要记思路就行，和 AI 沟通的思路。
8 01
文字沟通的实用技巧
曾经总结过一些只要注意，就能迅速让文字有所改观的技巧。工作中，写邮件、写文档都可以按照这个来。
1、一个段落不要太长，移动端超过五行可以起新段落。
2、段落和段落之间可以空一行，这样比较美观。
3、段首不需要缩进。
4、大块的文字可以用小标题隔开。
5、恰当使用标点符号。别一逗到底。
6、数字和英文前后可以加个空格。
7、先总后分，先结构后细节
8、少用大词，准确是第一要务。
曾经总结过一些只要注意，就能迅速让文字有所改观的技巧。工作中，写邮件、写文档都可以按照这个来。
1、一个段落不要太长，移动端超过五行可以起新段落。
2、段落和段落之间可以空一行，这样比较美观。
3、段首不需要缩进。
4、大块的文字可以用小标题隔开。
5、恰当使用标点符号。别一逗到底。
6、数字和英文前后可以加个空格。
7、先总后分，先结构后细节
8、少用大词，准确是第一要务。
16 11
Lenny 这期播客非常精彩，推荐在做 Vibe Coding 或者创业的朋友听一听。我听了大概一半，还没听完，但收获实在太多了。
所以就先停下来写一点笔记。这不是 Lenny 最新的一期，差点错过。嘉宾是 Mark Pincus，硅谷游戏公司 Zynga 的创始人。
他最近写了本新书，叫《Life at the Speed of Play》。查了一下，还没有中文版。这本书应该会大火，我感觉。
整个访谈我觉得核心表达了一个观点：
绝大多数成功产品，都没有从零发明全新的东西。它们先借用了市场上已经成立的模式，再做出明确的改善，最后加入一个足以吸引用户尝试的新变化。
超级有启发。对于很多有洁癖的 builder 来说，这个观点很有用。
www.youtube.com
一、产品成功的核心框架：Proven、Better、New
人的底层直觉通常是对的，具体想法却经常是错的。
比如，觉得人们需要更轻松的社交、更简单的游戏、更智能的相机，这种需求判断可能成立。
但设想出来的具体产品形态、功能和交互，大概率并不准确。
所以，创始人不要死守某个具体方案，而要保留背后的直觉，围绕它测试很多种产品形态。
这就是 Proven、Better、New 这套框架的出发点。
Proven 指市场上已经被验证过的产品规律。
不过这里有个前提。不能泛泛地说某类产品过去火过就算 Proven。得具体到今天这个平台上、这批用户、这个场景里，已经跑通的体验才算数。
比如，一个游戏在 90 年代很受欢迎，不代表今天放到手机上仍然成立。一个 PC 软件的操作方式，也不能直接证明它适合手机。平台变了，用户的耐心和习惯也跟着变了。
Sid Meier 是文明系列的创造者，PC 游戏设计的大师级人物。但他在 Facebook 上做社交游戏时，新手引导过于复杂，用户需要点击很多次才能进入游戏，大量人根本没有机会体验到后面的优秀设计。
后来他复盘，核心问题是团队没有先研究 Facebook 上已经跑通的游戏是怎么做新手引导的。
PC 玩家愿意花十分钟学规则，Facebook 用户点进来半分钟没玩上就走了。这两批人完全不一样。
所以，做新产品之前，先把同一个平台上已经做得好的产品研究透。如果连别人怎么做对的都不清楚，创新就无从谈起。
Better 是指几乎没有争议的改善。比如加载速度更快、操作步骤更少，这种不需要讨论好不好的改动。现有产品的十个用户看了，十个人都会点头说确实更好。
很多创始人容易把自己觉得有意思的功能叫做 Better。但只要用户之间还存在明显分歧，它更接近 New。
Better 往往是很小的改动，甚至看起来不够性感，但这些小改善会直接影响产品能否被用起来。
New 是产品真正新增的变化，也是宣传时最先拿出来讲的那个卖点。作用主要是吸引用户试一次。
但团队不要默认这个新功能一定成立。即使听起来很合理，它仍然可能失败。所以最好同时准备多个 New，快速轮换测试。
如果 Proven 做到位了，Better 也没问题，产品还是不行，那大概率是 New 选错了，换一个再试就好。反过来说，如果连 Proven 都没做好，加再多 New 也救不回来。
有时候甚至不需要 New。Slack 可能主要就是 Proven 加 Better：把人们已经在做的工作沟通变得更方便、更好用。用户通常不喜欢改变，只要把已有行为明显改善，就可能做出很大的产品。
二、很多创始人的障碍，是不愿意借鉴别人
这种心理有个说法叫 moral arbitrage。翻译过来大致是对借鉴的道德负担。
大多数创业者觉得借鉴丢人，主动回避，这反而给愿意借鉴的人留出了机会。别人不好意思做的事情，恰恰可以变成一种优势。
人们从小被教育，复制意味着作弊。很多创业者又把自己想象成创新者，本能地排斥已经存在的方案，希望从一张白纸开始。
但真正需要关注的是用户喜不喜欢，而不是同行觉得够不够原创。
当然，这不意味着照搬。好的产品会吸收已经验证过的模式，同时做出足够重要的改善。用户甚至不会明显感觉它来自某个旧产品，只会觉得它很自然、很好用。
创新就是 Mix。我们见过的所有的创新都是某种程度的 Mix。所以，真的没必要有洁癖。
举两个非常极端的例子。
Rovio 在做出愤怒的小鸟之前，连续做了 45 款游戏，每一款都很不同，最后终于碰中一个爆款。这像在荒野里不断打井，确实可能找到油，概率却很低。
OMGPOP 做 Draw Something 时走了另一条路。他们仔细研究了当时手机游戏里已经成立的玩法，也借用了 Words With Friends 的回合制机制，最后做出了 App Store 第一名。
两种路线都有可能成功，Proven、Better、New 的目标是提高成功概率。
先模仿，再超越。不丢人。
三、尽早关掉没有希望的产品
Kill hope before hope kills you.
这个观点我非常认可。很多产品跑了一段时间之后，数据不好，需求验证也有问题。
但因为创始团队亲手构建了这个产品，内心还是会觉得有希望。总觉得再发一次版、再调一下定位，事情就会好起来。
怎么判断产品到底有没有希望？
一个真正好的产品，信号是很强的。创始人自己会频繁使用，朋友体验后会主动推荐给别人，留存和增长的数据摆在那里不需要解释。
但很多产品没有这些信号。数据一般，用户反应也一般，创始人得靠分析、靠说服自己，才能相信产品有前途.....就是苦哈哈的坚持。
倒不一定说只要表现不好，就一定要快速关掉。至少创始团队不能麻痹自己。产品没有强烈的需求就是没有，这个时候应该承认事实，然后去分析能不能从中提取有效信息？附近有没有更强的需求？哪个部分已经出现了真实信号？要不要换一个 New 继续测试？
最危险的状态，是明明没有信号，却持续用融资、发布会和团队信心维持幻觉。
Mark 说自己刚刚关掉了一个持续四年、投入约 2500 万美元的元宇宙项目。项目过于宏大，一直没有找到产品市场匹配。
关掉以后，他反而在两周内产生了比过去四年更多的新想法。一个没有希望的项目会持续占据注意力和精力，关掉它，大家都会如释重负.....
放弃不一定是坏事。坚持也不一定就是什么优秀品质。
所以就先停下来写一点笔记。这不是 Lenny 最新的一期，差点错过。嘉宾是 Mark Pincus，硅谷游戏公司 Zynga 的创始人。
他最近写了本新书，叫《Life at the Speed of Play》。查了一下，还没有中文版。这本书应该会大火，我感觉。
整个访谈我觉得核心表达了一个观点：
绝大多数成功产品，都没有从零发明全新的东西。它们先借用了市场上已经成立的模式，再做出明确的改善，最后加入一个足以吸引用户尝试的新变化。
超级有启发。对于很多有洁癖的 builder 来说，这个观点很有用。
www.youtube.com
一、产品成功的核心框架：Proven、Better、New
人的底层直觉通常是对的，具体想法却经常是错的。
比如，觉得人们需要更轻松的社交、更简单的游戏、更智能的相机，这种需求判断可能成立。
但设想出来的具体产品形态、功能和交互，大概率并不准确。
所以，创始人不要死守某个具体方案，而要保留背后的直觉，围绕它测试很多种产品形态。
这就是 Proven、Better、New 这套框架的出发点。
Proven 指市场上已经被验证过的产品规律。
不过这里有个前提。不能泛泛地说某类产品过去火过就算 Proven。得具体到今天这个平台上、这批用户、这个场景里，已经跑通的体验才算数。
比如，一个游戏在 90 年代很受欢迎，不代表今天放到手机上仍然成立。一个 PC 软件的操作方式，也不能直接证明它适合手机。平台变了，用户的耐心和习惯也跟着变了。
Sid Meier 是文明系列的创造者，PC 游戏设计的大师级人物。但他在 Facebook 上做社交游戏时，新手引导过于复杂，用户需要点击很多次才能进入游戏，大量人根本没有机会体验到后面的优秀设计。
后来他复盘，核心问题是团队没有先研究 Facebook 上已经跑通的游戏是怎么做新手引导的。
PC 玩家愿意花十分钟学规则，Facebook 用户点进来半分钟没玩上就走了。这两批人完全不一样。
所以，做新产品之前，先把同一个平台上已经做得好的产品研究透。如果连别人怎么做对的都不清楚，创新就无从谈起。
Better 是指几乎没有争议的改善。比如加载速度更快、操作步骤更少，这种不需要讨论好不好的改动。现有产品的十个用户看了，十个人都会点头说确实更好。
很多创始人容易把自己觉得有意思的功能叫做 Better。但只要用户之间还存在明显分歧，它更接近 New。
Better 往往是很小的改动，甚至看起来不够性感，但这些小改善会直接影响产品能否被用起来。
New 是产品真正新增的变化，也是宣传时最先拿出来讲的那个卖点。作用主要是吸引用户试一次。
但团队不要默认这个新功能一定成立。即使听起来很合理，它仍然可能失败。所以最好同时准备多个 New，快速轮换测试。
如果 Proven 做到位了，Better 也没问题，产品还是不行，那大概率是 New 选错了，换一个再试就好。反过来说，如果连 Proven 都没做好，加再多 New 也救不回来。
有时候甚至不需要 New。Slack 可能主要就是 Proven 加 Better：把人们已经在做的工作沟通变得更方便、更好用。用户通常不喜欢改变，只要把已有行为明显改善，就可能做出很大的产品。
二、很多创始人的障碍，是不愿意借鉴别人
这种心理有个说法叫 moral arbitrage。翻译过来大致是对借鉴的道德负担。
大多数创业者觉得借鉴丢人，主动回避，这反而给愿意借鉴的人留出了机会。别人不好意思做的事情，恰恰可以变成一种优势。
人们从小被教育，复制意味着作弊。很多创业者又把自己想象成创新者，本能地排斥已经存在的方案，希望从一张白纸开始。
但真正需要关注的是用户喜不喜欢，而不是同行觉得够不够原创。
当然，这不意味着照搬。好的产品会吸收已经验证过的模式，同时做出足够重要的改善。用户甚至不会明显感觉它来自某个旧产品，只会觉得它很自然、很好用。
创新就是 Mix。我们见过的所有的创新都是某种程度的 Mix。所以，真的没必要有洁癖。
举两个非常极端的例子。
Rovio 在做出愤怒的小鸟之前，连续做了 45 款游戏，每一款都很不同，最后终于碰中一个爆款。这像在荒野里不断打井，确实可能找到油，概率却很低。
OMGPOP 做 Draw Something 时走了另一条路。他们仔细研究了当时手机游戏里已经成立的玩法，也借用了 Words With Friends 的回合制机制，最后做出了 App Store 第一名。
两种路线都有可能成功，Proven、Better、New 的目标是提高成功概率。
先模仿，再超越。不丢人。
三、尽早关掉没有希望的产品
Kill hope before hope kills you.
这个观点我非常认可。很多产品跑了一段时间之后，数据不好，需求验证也有问题。
但因为创始团队亲手构建了这个产品，内心还是会觉得有希望。总觉得再发一次版、再调一下定位，事情就会好起来。
怎么判断产品到底有没有希望？
一个真正好的产品，信号是很强的。创始人自己会频繁使用，朋友体验后会主动推荐给别人，留存和增长的数据摆在那里不需要解释。
但很多产品没有这些信号。数据一般，用户反应也一般，创始人得靠分析、靠说服自己，才能相信产品有前途.....就是苦哈哈的坚持。
倒不一定说只要表现不好，就一定要快速关掉。至少创始团队不能麻痹自己。产品没有强烈的需求就是没有，这个时候应该承认事实，然后去分析能不能从中提取有效信息？附近有没有更强的需求？哪个部分已经出现了真实信号？要不要换一个 New 继续测试？
最危险的状态，是明明没有信号，却持续用融资、发布会和团队信心维持幻觉。
Mark 说自己刚刚关掉了一个持续四年、投入约 2500 万美元的元宇宙项目。项目过于宏大，一直没有找到产品市场匹配。
关掉以后，他反而在两周内产生了比过去四年更多的新想法。一个没有希望的项目会持续占据注意力和精力，关掉它，大家都会如释重负.....
放弃不一定是坏事。坚持也不一定就是什么优秀品质。
15 48
民宿的小姐姐和我吐槽：
内蒙古的营商环境真差。我们给景区这边反馈的问题，他们一向都是左耳朵进，右耳朵出。但当他们有要求时，我们却得立刻执行，半点商量空间都没有。
你看老牛湾底下这些粉色造型的装饰，很多游客都说难看，跟风景格格不入。我把大家的意见转达给景区领导，他只回了句：游客的意见听听就好，我觉得这个设计挺棒的，继续干。
哎。领导的审美真一言难尽。
内蒙古的营商环境真差。我们给景区这边反馈的问题，他们一向都是左耳朵进，右耳朵出。但当他们有要求时，我们却得立刻执行，半点商量空间都没有。
你看老牛湾底下这些粉色造型的装饰，很多游客都说难看，跟风景格格不入。我把大家的意见转达给景区领导，他只回了句：游客的意见听听就好，我觉得这个设计挺棒的，继续干。
哎。领导的审美真一言难尽。
8 02
这简直就是WAIC最值得听的演讲。
刚刚进入 2026 年下半年，AI 的进展依然非常快，信息多得让人有点喘不过气来。
在这样的时间节点，再听听阶跃董事长、千里科技董事长印奇 WAIC 在主论坛开幕式上讲他对 AI 发展脉络的理解，还是让我很受启发。
我想写写自己的感触。前奏可能有点长，因为印奇提到说他发现过去 70 年来 AI 技术的发展脉络，呈现出高度的连续性。
恰好这段时间我在看《人工智能简史》，深有感触。记得丘吉尔说过，你能看到多远的过去，就能看到多远的未来。
1
过去 70 年，人工智能一直在解决一个问题：怎么让机器拥有接近人类的通用智能？
最早影响很大的一条路线是符号主义。基本想法是把人的知识和推理过程写成一套符号与规则。
比如，如果发生 A，就执行 B。满足某几个条件，就可以推出一个结论。
这个思路很好理解。既然人会根据规则推理，那就把规则教给机器。可现实世界太复杂了，规则无法穷举。
后来，机器学习逐渐成为主流。人们不再试图把所有规则一条条写给机器，而是让它自己从数据中寻找规律。
比如给模型看大量猫和狗的图片，经过训练之后，它逐渐能够判断一张新图片里出现的是猫还是狗。
再之后，深度学习和大模型把这条路线推到了新的高度。尤其是过去几年，模型开始拥有比较强的语言理解、内容生成和推理能力。
AI 第一次能够比较自然地和人交流，也能够处理过去很难通过固定规则解决的问题。
顺着这个框架继续往下看，到了 2026 年，大模型其实又走到了一个新的节点。
大家有没有发现，去年国内几家大厂还在争论元宝、千问、豆包这些聊天产品谁能抢到用户入口。
今年，大家争抢的重点已经慢慢变成了 Agent 入口。
因为过去我们使用 AI，主要还是让它回答问题，或者完成一个很短的任务。
现在的 Agent 已经开始处理持续几个小时甚至几十个小时的复杂任务。而且，AI 对于编程语言的驾驭能力也逐步超过人类。
Agent 的条件已经成熟。AI 从模仿人类逐步开始在部分任务上超越人类。
2
还有一个让我恍然大悟的观点，印奇说他发现这些年 AI 的发展过程中，所有的重要里程碑都和语言紧密相关。
维特根斯坦说过：语言的边界，就是世界的边界。大概意思是，人能够理解什么，很大程度取决于语言。
没有语言描述的东西，人就很难思考。比如一个人如果没有颜色的概念，他就很难理解红色。
对 AI 也一样。
如果 AI 只理解自然语言，它主要能进入的就是文字、知识和对话的世界。我们告诉它一件事情，它能够听懂。
我们问它一个问题，它能够回答。这已经非常重要，但它的能力大部分还停留在语言里。
这两年，Agent 能力突飞猛进的原因之一就是因为模型充分掌握了编程语言。
因为代码可以调用 API、读取数据库、操作软件、修改文件、控制系统。
AI 一旦能够理解和生成代码，就相当于拿到了进入整个计算机世界的一把通用钥匙。
这也是为什么过去一两年，模型 Coding 能力如此重要。编程语言会扩展 Agent 的边界。
紧接着，还有一个判断：Agent 肯定会成为未来生产力的最小单元。
过去的软件，其实没有资格成为一个独立的生产单元。Excel 很强，Photoshop 很强，搜索引擎也很强，但它们仍然是工具。
真正理解目标、拆解任务、检查结果的，始终是人。所以过去一个组织里，最小的执行单元通常是一个人或者一个岗位。
Agent 带来的变化，是它开始能够独立跑完一段相对完整的工作闭环。
我们给它一个目标，它可以自己拆解、调用资源、执行操作、检查结果，然后交付成果。
打个比方，过去的软件像车床和传送带，每台机器只能处理一个步骤，需要工人在中间操作和衔接。
Agent 更像一个可以独立接收任务的工作站，原料交给它，它能够自己安排步骤，处理过程中出现的问题，最后交付一个相对完整的产出。
或者这么讲，过去的软件，本质上增强人的能力。而 Agent，会直接成为生产过程的一部分。
一旦 Agent 成为这种基本执行单元，整个生产力的组织方式都会跟着变化。
3
会发生什么变化呢？简单来说，印奇认为会出现新系统、新载体、新网络。我分别讲下自己的理解。
第一个是新的系统。
过去几十年，每次计算平台发生重大变化，操作系统都会随之变化。
PC 时代出现了 Windows 和 macOS，主要负责管理电脑上的硬件、文件和软件。
移动互联网时代出现了 Android 和 iOS，手机上多了摄像头、定位、通知和各种传感器，操作系统需要把这些能力管理起来，再开放给不同的 App。
到了 Agent 时代，操作系统需要管理智能体的身份、权限、记忆和协作等等。
所以演讲里提出了一个公式：智能体能力，等于模型能力 × Agent 操作系统能力。模型像大脑，决定 Agent 能不能理解和思考。
Agent OS 负责把模型和外部世界连接起来，给它提供记忆、工具、数据、权限和运行环境。
这一点我听完还是挺有启发的。从 PC 到移动到 Agent，每一次平台变化，操作系统管理的对象都不一样，这条脉络一拉出来就很清楚。
第二个是新的载体。
相信看到这里，大家就能理解为什么 OpenAI 会做硬件了。
移动互联网时代，手机这样的终端主要负责连接人与数字世界，所有操作都由人来完成。
到了 Agent 时代，终端会重新围绕 Agent 来设计。
比如过去出门旅行，我们需要自己打开地图、查看日程、搜索航班，再分别处理各种信息。
未来 Agent 可能已经知道我们的行程，看到航班延误之后，主动调整后面的安排，并把新的方案告诉我们。这完全是不同的逻辑。
所以这一轮所谓的 AI 硬件，真正要解决的，可能也不是在现有设备上增加一个聊天入口。
大家都在寻找一种更适合智能体长期存在、持续感知和随时行动的载体。
它可能仍然是手机，也可能是耳机、眼镜、汽车或者机器人。
具体最后会长成什么样，现在还很难判断，但可以确定的是，一定会有新的载体出现。
第三个是新的网络。
互联网连接的是人、信息和服务。到了 Agent 时代，还会出现大量智能体之间的连接，也就是 A2A 网络。
最近我就在公司里搭了一个很小的 Agent 局域网，让不同同事的 Agent 可以互相发送任务、同步进度。
比如我的 Agent 发现一个产品问题，可以直接把问题交给研发同事的 Agent，后者分析原因、尝试修复，再把结果发回来。
当然，这套东西现在还很早期。诸如权限怎么管理，传递的信息出了错又该由谁负责，都还没有成熟的答案。
但只要 Agent 能够独立承接任务，它们之间产生连接和协作，就是很自然的结果。一个 Agent 不可能擅长所有事情，它也需要寻找其他 Agent，分配任务，再把结果整合起来。
很有启发。提纲挈领。
刚刚进入 2026 年下半年，AI 的进展依然非常快，信息多得让人有点喘不过气来。
在这样的时间节点，再听听阶跃董事长、千里科技董事长印奇 WAIC 在主论坛开幕式上讲他对 AI 发展脉络的理解，还是让我很受启发。
我想写写自己的感触。前奏可能有点长，因为印奇提到说他发现过去 70 年来 AI 技术的发展脉络，呈现出高度的连续性。
恰好这段时间我在看《人工智能简史》，深有感触。记得丘吉尔说过，你能看到多远的过去，就能看到多远的未来。
1
过去 70 年，人工智能一直在解决一个问题：怎么让机器拥有接近人类的通用智能？
最早影响很大的一条路线是符号主义。基本想法是把人的知识和推理过程写成一套符号与规则。
比如，如果发生 A，就执行 B。满足某几个条件，就可以推出一个结论。
这个思路很好理解。既然人会根据规则推理，那就把规则教给机器。可现实世界太复杂了，规则无法穷举。
后来，机器学习逐渐成为主流。人们不再试图把所有规则一条条写给机器，而是让它自己从数据中寻找规律。
比如给模型看大量猫和狗的图片，经过训练之后，它逐渐能够判断一张新图片里出现的是猫还是狗。
再之后，深度学习和大模型把这条路线推到了新的高度。尤其是过去几年，模型开始拥有比较强的语言理解、内容生成和推理能力。
AI 第一次能够比较自然地和人交流，也能够处理过去很难通过固定规则解决的问题。
顺着这个框架继续往下看，到了 2026 年，大模型其实又走到了一个新的节点。
大家有没有发现，去年国内几家大厂还在争论元宝、千问、豆包这些聊天产品谁能抢到用户入口。
今年，大家争抢的重点已经慢慢变成了 Agent 入口。
因为过去我们使用 AI，主要还是让它回答问题，或者完成一个很短的任务。
现在的 Agent 已经开始处理持续几个小时甚至几十个小时的复杂任务。而且，AI 对于编程语言的驾驭能力也逐步超过人类。
Agent 的条件已经成熟。AI 从模仿人类逐步开始在部分任务上超越人类。
2
还有一个让我恍然大悟的观点，印奇说他发现这些年 AI 的发展过程中，所有的重要里程碑都和语言紧密相关。
维特根斯坦说过：语言的边界，就是世界的边界。大概意思是，人能够理解什么，很大程度取决于语言。
没有语言描述的东西，人就很难思考。比如一个人如果没有颜色的概念，他就很难理解红色。
对 AI 也一样。
如果 AI 只理解自然语言，它主要能进入的就是文字、知识和对话的世界。我们告诉它一件事情，它能够听懂。
我们问它一个问题，它能够回答。这已经非常重要，但它的能力大部分还停留在语言里。
这两年，Agent 能力突飞猛进的原因之一就是因为模型充分掌握了编程语言。
因为代码可以调用 API、读取数据库、操作软件、修改文件、控制系统。
AI 一旦能够理解和生成代码，就相当于拿到了进入整个计算机世界的一把通用钥匙。
这也是为什么过去一两年，模型 Coding 能力如此重要。编程语言会扩展 Agent 的边界。
紧接着，还有一个判断：Agent 肯定会成为未来生产力的最小单元。
过去的软件，其实没有资格成为一个独立的生产单元。Excel 很强，Photoshop 很强，搜索引擎也很强，但它们仍然是工具。
真正理解目标、拆解任务、检查结果的，始终是人。所以过去一个组织里，最小的执行单元通常是一个人或者一个岗位。
Agent 带来的变化，是它开始能够独立跑完一段相对完整的工作闭环。
我们给它一个目标，它可以自己拆解、调用资源、执行操作、检查结果，然后交付成果。
打个比方，过去的软件像车床和传送带，每台机器只能处理一个步骤，需要工人在中间操作和衔接。
Agent 更像一个可以独立接收任务的工作站，原料交给它，它能够自己安排步骤，处理过程中出现的问题，最后交付一个相对完整的产出。
或者这么讲，过去的软件，本质上增强人的能力。而 Agent，会直接成为生产过程的一部分。
一旦 Agent 成为这种基本执行单元，整个生产力的组织方式都会跟着变化。
3
会发生什么变化呢？简单来说，印奇认为会出现新系统、新载体、新网络。我分别讲下自己的理解。
第一个是新的系统。
过去几十年，每次计算平台发生重大变化，操作系统都会随之变化。
PC 时代出现了 Windows 和 macOS，主要负责管理电脑上的硬件、文件和软件。
移动互联网时代出现了 Android 和 iOS，手机上多了摄像头、定位、通知和各种传感器，操作系统需要把这些能力管理起来，再开放给不同的 App。
到了 Agent 时代，操作系统需要管理智能体的身份、权限、记忆和协作等等。
所以演讲里提出了一个公式：智能体能力，等于模型能力 × Agent 操作系统能力。模型像大脑，决定 Agent 能不能理解和思考。
Agent OS 负责把模型和外部世界连接起来，给它提供记忆、工具、数据、权限和运行环境。
这一点我听完还是挺有启发的。从 PC 到移动到 Agent，每一次平台变化，操作系统管理的对象都不一样，这条脉络一拉出来就很清楚。
第二个是新的载体。
相信看到这里，大家就能理解为什么 OpenAI 会做硬件了。
移动互联网时代，手机这样的终端主要负责连接人与数字世界，所有操作都由人来完成。
到了 Agent 时代，终端会重新围绕 Agent 来设计。
比如过去出门旅行，我们需要自己打开地图、查看日程、搜索航班，再分别处理各种信息。
未来 Agent 可能已经知道我们的行程，看到航班延误之后，主动调整后面的安排，并把新的方案告诉我们。这完全是不同的逻辑。
所以这一轮所谓的 AI 硬件，真正要解决的，可能也不是在现有设备上增加一个聊天入口。
大家都在寻找一种更适合智能体长期存在、持续感知和随时行动的载体。
它可能仍然是手机，也可能是耳机、眼镜、汽车或者机器人。
具体最后会长成什么样，现在还很难判断，但可以确定的是，一定会有新的载体出现。
第三个是新的网络。
互联网连接的是人、信息和服务。到了 Agent 时代，还会出现大量智能体之间的连接，也就是 A2A 网络。
最近我就在公司里搭了一个很小的 Agent 局域网，让不同同事的 Agent 可以互相发送任务、同步进度。
比如我的 Agent 发现一个产品问题，可以直接把问题交给研发同事的 Agent，后者分析原因、尝试修复，再把结果发回来。
当然，这套东西现在还很早期。诸如权限怎么管理，传递的信息出了错又该由谁负责，都还没有成熟的答案。
但只要 Agent 能够独立承接任务，它们之间产生连接和协作，就是很自然的结果。一个 Agent 不可能擅长所有事情，它也需要寻找其他 Agent，分配任务，再把结果整合起来。
很有启发。提纲挈领。
66 346
好喜欢这次旅行。内蒙老牛湾。
晚上在黄河边，看到了漫天星斗，小孩子们兴奋的睡不着，在城市里待久了，他们不知道天上可以有那么多星星。
而我呢，喝了点酒，想起了史铁生写的《奶奶的星星》。记得书里说，人死了，就会变成一颗星星。那么，我的奶奶呢？她是不是也在这片星空里，看着我呢？
我仰着头，在这浩瀚深蓝的夜空找寻。
晚上在黄河边，看到了漫天星斗，小孩子们兴奋的睡不着，在城市里待久了，他们不知道天上可以有那么多星星。
而我呢，喝了点酒，想起了史铁生写的《奶奶的星星》。记得书里说，人死了，就会变成一颗星星。那么，我的奶奶呢？她是不是也在这片星空里，看着我呢？
我仰着头，在这浩瀚深蓝的夜空找寻。
7 01
给我的个人博客做了一个About Me页面。Kimi K3 确实不错。大家感受下：xiaogai.fun
01:00
30 128
能力不够，努力也不够，然后一遇到点挫折就唧唧歪歪喊委屈，找解释，希望获得别人的理解和同情，以维护自己光大伟正的形象。反正我是不允许自己成为这样的人。
哪有那么多委屈啊。摔倒了，拍拍身上的灰尘，咱继续往前走，乐乐呵呵的。关关难过关关过，不等不靠不幻想。
哪有那么多委屈啊。摔倒了，拍拍身上的灰尘，咱继续往前走，乐乐呵呵的。关关难过关关过，不等不靠不幻想。
21 43
分享下我使用 Codex 的一些习惯。
给大家分享六个我在 Codex 中会高频用到的提示词，感觉也是一个使用 AI 的习惯。
最近硅谷又开始流行一个概念，叫 Loop Engineering。
简单来说，就是让 Agent 在一个任务中持续执行、检查、修正，直到达到目标。
我觉得它和 Prompt Engineering 依然有很多弯弯绕绕的关系。到今天为止，无论是用 ChatGPT 还是 Codex 这样的 Agent，提示词依然很重要。
模型能力再强，我们怎么和它沟通，会直接影响最终的产出。
不过，今天的提示词已经不需要写成八股文了。不需要每次都套一套复杂的格式，提示词说到底就是我们和 AI 交互的思路。
跟和同事沟通是一个道理，沟通方法不同，达成的结果往往也不一样。
下面是我最近使用 Codex 时，最常用的六个提示词思路。注意，重点是思路。具体怎么问，可以根据自己的任务随时调整。
一、从何而来，何以至此
遇到一个复杂概念，比如一篇论文、一个新的技术框架，想快速搞懂它，效率最低的方法往往是从第一行开始，一行一行往下看。
看了半天，记住了很多术语，却不知道作者为什么要研究这个问题，它和以前的方法有什么关系，也不知道这篇论文真正重要的地方在哪里。
这时候，我通常会先问 Codex：
详细总结这个论文解决了什么问题，思路是什么？有什么非共识的判断。
因为我觉得理解一个概念，第一步是搞清楚它从何而来，何以至此。
没必要急着深入到细节，而是应该往回倒，想一想为什么会是这样，到底要解决什么问题，又是怎么一步一步走到现在的。
很多知识单独拿出来看，会显得非常抽象。一旦知道它是为了解决什么问题、之前别人是怎么做的，就会立马明白其中的逻辑。
比如一篇论文提出了一套新的架构，先不用急着看每一个公式。
搞清楚旧架构遇到了什么问题，为什么继续增加参数、增加数据或者调整训练方法已经解决不了。脉络理出来之后，后面的细节就容易理解了。
二、让 AI 指出我的思维盲区
我在和 Codex 协作时，如果自己对方向比较确定，通常会不断地告诉它需求和想法。
Codex 一般都会顺着这个方向执行，完成得也还不错。
这种场景下，Codex 扮演的还是执行者。我告诉它要做什么，它就会尽可能做好。
只要当前方案能成立，它通常不会跳出来挑战我们的判断。
但其实协作过程中，Codex 会阅读相关材料，看过完整代码，知道我们为什么这样改，也知道前面做过哪些取舍。
很多时候，它掌握的上下文甚至比其他参与者还完整。
所以做完一个相对完整的任务之后，我会让 Codex 暂时跳出执行者的角色，重新审视整个过程，然后问它：
从刚才这个任务来看，我的思维盲区是什么？
这时候 Codex 会基于上下文以及它对于这件事情的理解，列出来可能存在的思维盲区。
多数情况下，Codex 反馈的这些新的视角对我来说都有很多启发。大家可以试试。
三、让 AI 反思它最没把握的地方
还有的时候，我们会给 Codex 一个相对复杂的需求，让它自己搞定。Codex 可能会花很长时间执行。
这个过程中，很多决定是 Codex 自己做的，诸如用什么方案，怎么实现。
最后做完之后， Codex 基本上也会用比较确定的语气说它搞定了，然后列出来自己做了什么。
但其实，AI 也有自己的盲点。所以，在进入细节看具体的实现之前，我会先问：
重新反思一下，刚才执行过程中最没把握的地方有哪些？
再或者，还可以继续要求说得更具体：哪些结论经过了实际验证？有哪些问题暂时无法确认？
这样一问，Codex 通常会主动把风险暴露出来。
比如某个接口没有真实环境所以没跑完整测试，某段代码看起来已经废弃但无法百分之百确认，某个功能只测了正常流程没有覆盖异常输入，或者为了兼容旧逻辑选了一个保守方案但不确定是不是我们真正想要的。
这些信息非常重要。
四、让 AI 用大白话讲清楚它的逻辑
AI 做长程任务的时候，速度肯定是人的几十倍。我们不可能每次都逐行检查代码。即使看了，也未必能快速理解它为什么这么改。
这时候，我通常会直接问：
言简意赅地讲一下，刚才这个任务的解决逻辑是什么。不要逐个文件介绍，用通俗易懂的话讲清楚就行。
也可以问得更具体：
这个问题原来为什么会出现？做了哪几项关键修改？修改之后这套逻辑是怎么运行的？后面最容易出问题的地方在哪里？
这个提示词看起来简单，但我觉得特别重要。当 AI 可以独立完成越来越多工作之后，人很容易只关注最后的结果。只要功能正确，就皆大欢喜。
但时间长了以后，我们会逐渐失去对项目的理解。这种理解层面的让渡非常可怕，因为后面一旦 AI 出问题，搞不定了，需要我们接手，那我们面对的可能完全是一个黑盒。
所以我会要求 Codex 把关键逻辑讲到我能听懂。
比如它可以这样解释：以前每次切换页面，系统都会重新请求一次数据，所以页面会闪烁。
我现在把数据放进了共享缓存里，第一次打开时请求，之后优先读取缓存，缓存过期之后再重新更新。
这样的解释没有太多代码细节，但我们很容易理解。理解之后才能继续判断这个方案是否符合预期，缓存多久合适，会不会出现数据更新不及时的问题，下一步应该怎么继续。
代码可以交给 AI 写，很多细节也可以让 AI 处理。但关键逻辑，最好还是让它讲到我们真正理解。
五、让 AI 做结构化的信息呈现
有些事情，AI 用文字讲了很多，我们还是很难理解。特别是系统架构、数据流、业务流程、模块依赖这些内容。它写了三四段，看的人云里雾里。
这时候我一般不会继续让它再换一种文字表达，而是直接说：
能不能给我做一张图，把这套逻辑表达清楚？具体用什么图，根据场景来定。
流程图适合表达任务的执行顺序，架构图适合说明前后端和数据库之间的关系，脑图适合整理功能结构，时序图适合展示一次完整请求的过程，对比图适合说明修改前后的区别。
Codex 现在已经可以调用图像生成能力，也可以生成 Mermaid、Excalidraw、HTML 图表等不同形式的图。
六、表达完需求后，先让 AI 确认理解
给 Codex 说完需求，它会马上开始执行。但注意，我们表达需求的时候，本来就很容易遗漏信息。
特别是现在用语音输入法，表达可能东一句西一句。Codex 只能根据有限的信息去猜。一旦最开始理解错了，后面执行得越认真，浪费的时间越多。
所以我表达完需求之后，经常会紧接着说：
先看看是否理解了我的需求，不要开始执行。有不理解的地方直接追问我，追问清楚之后再继续。
或者有时候也会让它把理解复述一遍：
先用自己的话复述一下我的目标、限制条件和最终要交付的结果。
这一小步，真的可以提前消除很多误会。
给大家分享六个我在 Codex 中会高频用到的提示词，感觉也是一个使用 AI 的习惯。
最近硅谷又开始流行一个概念，叫 Loop Engineering。
简单来说，就是让 Agent 在一个任务中持续执行、检查、修正，直到达到目标。
我觉得它和 Prompt Engineering 依然有很多弯弯绕绕的关系。到今天为止，无论是用 ChatGPT 还是 Codex 这样的 Agent，提示词依然很重要。
模型能力再强，我们怎么和它沟通，会直接影响最终的产出。
不过，今天的提示词已经不需要写成八股文了。不需要每次都套一套复杂的格式，提示词说到底就是我们和 AI 交互的思路。
跟和同事沟通是一个道理，沟通方法不同，达成的结果往往也不一样。
下面是我最近使用 Codex 时，最常用的六个提示词思路。注意，重点是思路。具体怎么问，可以根据自己的任务随时调整。
一、从何而来，何以至此
遇到一个复杂概念，比如一篇论文、一个新的技术框架，想快速搞懂它，效率最低的方法往往是从第一行开始，一行一行往下看。
看了半天，记住了很多术语，却不知道作者为什么要研究这个问题，它和以前的方法有什么关系，也不知道这篇论文真正重要的地方在哪里。
这时候，我通常会先问 Codex：
详细总结这个论文解决了什么问题，思路是什么？有什么非共识的判断。
因为我觉得理解一个概念，第一步是搞清楚它从何而来，何以至此。
没必要急着深入到细节，而是应该往回倒，想一想为什么会是这样，到底要解决什么问题，又是怎么一步一步走到现在的。
很多知识单独拿出来看，会显得非常抽象。一旦知道它是为了解决什么问题、之前别人是怎么做的，就会立马明白其中的逻辑。
比如一篇论文提出了一套新的架构，先不用急着看每一个公式。
搞清楚旧架构遇到了什么问题，为什么继续增加参数、增加数据或者调整训练方法已经解决不了。脉络理出来之后，后面的细节就容易理解了。
二、让 AI 指出我的思维盲区
我在和 Codex 协作时，如果自己对方向比较确定，通常会不断地告诉它需求和想法。
Codex 一般都会顺着这个方向执行，完成得也还不错。
这种场景下，Codex 扮演的还是执行者。我告诉它要做什么，它就会尽可能做好。
只要当前方案能成立，它通常不会跳出来挑战我们的判断。
但其实协作过程中，Codex 会阅读相关材料，看过完整代码，知道我们为什么这样改，也知道前面做过哪些取舍。
很多时候，它掌握的上下文甚至比其他参与者还完整。
所以做完一个相对完整的任务之后，我会让 Codex 暂时跳出执行者的角色，重新审视整个过程，然后问它：
从刚才这个任务来看，我的思维盲区是什么？
这时候 Codex 会基于上下文以及它对于这件事情的理解，列出来可能存在的思维盲区。
多数情况下，Codex 反馈的这些新的视角对我来说都有很多启发。大家可以试试。
三、让 AI 反思它最没把握的地方
还有的时候，我们会给 Codex 一个相对复杂的需求，让它自己搞定。Codex 可能会花很长时间执行。
这个过程中，很多决定是 Codex 自己做的，诸如用什么方案，怎么实现。
最后做完之后， Codex 基本上也会用比较确定的语气说它搞定了，然后列出来自己做了什么。
但其实，AI 也有自己的盲点。所以，在进入细节看具体的实现之前，我会先问：
重新反思一下，刚才执行过程中最没把握的地方有哪些？
再或者，还可以继续要求说得更具体：哪些结论经过了实际验证？有哪些问题暂时无法确认？
这样一问，Codex 通常会主动把风险暴露出来。
比如某个接口没有真实环境所以没跑完整测试，某段代码看起来已经废弃但无法百分之百确认，某个功能只测了正常流程没有覆盖异常输入，或者为了兼容旧逻辑选了一个保守方案但不确定是不是我们真正想要的。
这些信息非常重要。
四、让 AI 用大白话讲清楚它的逻辑
AI 做长程任务的时候，速度肯定是人的几十倍。我们不可能每次都逐行检查代码。即使看了，也未必能快速理解它为什么这么改。
这时候，我通常会直接问：
言简意赅地讲一下，刚才这个任务的解决逻辑是什么。不要逐个文件介绍，用通俗易懂的话讲清楚就行。
也可以问得更具体：
这个问题原来为什么会出现？做了哪几项关键修改？修改之后这套逻辑是怎么运行的？后面最容易出问题的地方在哪里？
这个提示词看起来简单，但我觉得特别重要。当 AI 可以独立完成越来越多工作之后，人很容易只关注最后的结果。只要功能正确，就皆大欢喜。
但时间长了以后，我们会逐渐失去对项目的理解。这种理解层面的让渡非常可怕，因为后面一旦 AI 出问题，搞不定了，需要我们接手，那我们面对的可能完全是一个黑盒。
所以我会要求 Codex 把关键逻辑讲到我能听懂。
比如它可以这样解释：以前每次切换页面，系统都会重新请求一次数据，所以页面会闪烁。
我现在把数据放进了共享缓存里，第一次打开时请求，之后优先读取缓存，缓存过期之后再重新更新。
这样的解释没有太多代码细节，但我们很容易理解。理解之后才能继续判断这个方案是否符合预期，缓存多久合适，会不会出现数据更新不及时的问题，下一步应该怎么继续。
代码可以交给 AI 写，很多细节也可以让 AI 处理。但关键逻辑，最好还是让它讲到我们真正理解。
五、让 AI 做结构化的信息呈现
有些事情，AI 用文字讲了很多，我们还是很难理解。特别是系统架构、数据流、业务流程、模块依赖这些内容。它写了三四段，看的人云里雾里。
这时候我一般不会继续让它再换一种文字表达，而是直接说：
能不能给我做一张图，把这套逻辑表达清楚？具体用什么图，根据场景来定。
流程图适合表达任务的执行顺序，架构图适合说明前后端和数据库之间的关系，脑图适合整理功能结构，时序图适合展示一次完整请求的过程，对比图适合说明修改前后的区别。
Codex 现在已经可以调用图像生成能力，也可以生成 Mermaid、Excalidraw、HTML 图表等不同形式的图。
六、表达完需求后，先让 AI 确认理解
给 Codex 说完需求，它会马上开始执行。但注意，我们表达需求的时候，本来就很容易遗漏信息。
特别是现在用语音输入法，表达可能东一句西一句。Codex 只能根据有限的信息去猜。一旦最开始理解错了，后面执行得越认真，浪费的时间越多。
所以我表达完需求之后，经常会紧接着说：
先看看是否理解了我的需求，不要开始执行。有不理解的地方直接追问我，追问清楚之后再继续。
或者有时候也会让它把理解复述一遍：
先用自己的话复述一下我的目标、限制条件和最终要交付的结果。
这一小步，真的可以提前消除很多误会。
79 434