你可能会问：“你说会聊天比会写代码重要，但什么叫‘会聊天’？跟AI聊天不就是打字说话吗？”

我的理解是这样的。

会聊天，不是跟AI唠嗑，也不是写一段很长的提示词把需求全部塞给它。而是用一种“你问我答”的方式，来回对齐信息。

AI不知道你脑子里在想什么。它只能通过你给它的文字来推断你的意图。如果你的描述里带了个人偏好、模糊词汇，或者你自己也没想清楚到底要什么，AI就会开始猜。你猜它的理解对不对，它猜你想要什么，双方都在猜，谁也落不了地。

所以“会聊天”的核心不是表达，是确认。AI应该先问你问题，一个一个问，直到你听到某个选项时说“对，就是这个”。方向对齐了，再开始做。

我之前一直用的方法是：让AI润色文本的时候，在开头写一句“请保留下面对话中80%的我自己原文的文风和风格，仅做20%的错别字、标点、语病、冗余口水词的润色”。但每次改完读起来，还是觉得“不太对”。哪里不对，一次性说不出来。

后来我换了一段提示词。我直接告诉AI：在执行任务之前先想清楚四件事，然后不厌其烦地问我关于方案的每一个方面，直到我们达成共识。每个问题给出推荐的答案，一次只问一个问题，等我回答之后再问下一个。用具体场景来压力测试设计。我把这段话整个贴给它，让AI自己读，自己按这个逻辑来问我。

试了几轮之后，发现方向对了。

这个问题不只是我一个人遇到。很多人用豆包或者其他模型的时候也有类似的感觉——答非所问、跑偏、越用越火大，但具体哪里出了问题，说不清楚。后来发现根源是一样的：AI在猜你的意图，你也在猜AI的理解，双方都在猜，谁也落不了地。

那这段提示词的核心逻辑就是：不厌其烦地追问，直到把脑海里所有模糊的想法都榨干。在动笔之前，先问清楚方向。方向对齐了，再开始写。

就像我和DeepSeek打磨这篇文章的过程。我让它写开头，它没有直接写，而是一个问题一个问题地问我：你要写给谁看？你想表达什么？你希望用什么语气？这些问题来回问了很久，直到它完全理解了我脑子里那团模糊的东西，才开始动笔。

你正在读的这篇，就是这么出来的。

关于本文的一些说明

这篇文章的写作，最初是因为我在ZD论坛（争渡论坛，一个盲人论坛）上读到一篇关于AI Agent Coding实战分享的文章，觉得非常有启发，原本想直接转载到公众号。但了解到作者原本有付费订阅的打算，直接转载不太合适。所以我在学习那篇文章的基础上，结合自己用AI开发“梦仔伴唱”的实际经历，从自己的视角重新整理和讲述。文中提到的部分方法论（如聪明区管理、Grill、Superpowers等）受到那篇文章的启发，但具体的实践案例、踩坑记录和操作细节均来自我个人的真实体验。

那篇原文写得非常好，如果你感兴趣，可以去阅读完整版本：https://www.zd.hk/thread-177275.htm

在此向原作者表示感谢和尊重。

我完全不懂代码，一行代码都看不懂。但我最近靠AI写出了一个能用的Android应用，叫梦仔伴唱。当然过程没那么顺利。我提需求，AI写代码，我安装试用，发现不能用，回来吐槽，AI再改。循环往复，折腾了十几个版本。但我慢慢摸到了一些门道。

这篇文章的核心就一句话：只要你会表达，在这种AI协作的方式下，是有无限可能的。

第一章 别急着写代码——先搭好你的地基

为什么我让你先搞日志

你可能会说，软件都还没写呢，搞什么日志？

我遇到过一个事。梦仔伴唱在华为鸿蒙3.0（Android 10）上，部分用户打开搜索页面或设置页面直接闪退。起初我完全不知道是什么原因。用户反馈说“打开设置就崩了”，就这一句话。我在群里问朋友，有人建议我做一个崩溃时自动把日志写入剪切板的功能，这样用户崩溃后直接粘贴发给我，我再把日志给AI看。试了一下，AI读完日志直接定位到问题——stateDescription在鸿蒙3.0上调用崩溃了，因为这个属性是Android 11才正式支持的，鸿蒙3.0虽然底层是Android 10，但声称支持部分API 30的特性，实际调用直接崩。

我后来让AI写了一个兼容方法：

```kotlin

fun View.setStateDescriptionCompat(desc: CharSequence?) {

try { stateDescription = desc } catch (_: Throwable) {}

}

```

所有设置stateDescription的地方都调这个方法，不直接赋值。try-catch确保即使系统不支持也不会崩。

还有一个坑。Android 10及以下，GradientDrawable的gradient标签angle必须是45的倍数。写个160，新版Android没事，Android 10直接崩。我们后来统一全用45的倍数。

这两个问题如果当时没有日志，靠我自己描述现象、录屏、截图，永远查不到。我看不懂代码，截了图发给AI，AI也看不出来——它不能从截图里读出某个属性调用了哪个API。但把崩溃日志给它，它能精准定位到是哪一行、哪个方法、什么条件下出了问题。

所以我的建议是：在让AI写任何功能之前，先让它写一个日志系统。要覆盖所有运行逻辑，能自动捕获异常，最重要的是崩溃时自动把日志写入设备剪切板。用户崩溃后直接粘贴发给你，你再转给AI。

先跑通逻辑，再管界面

不懂编程的人最容易犯的错：让AI直接生成一个“完美”的界面。上来就问AI要一个好看的UI。

但好看是什么？AI不知道你脑子里的好看是什么样。它只能去网上找“大家觉得好看”的东西，然后搬过来。网络数据繁杂，充斥着过时甚至错误的信息。当很多人觉得某个设计是对的，AI就默认它是权威。它把这个“大家觉得对”的东西带到你的项目里，结果可想而知。

很多盲人圈的软件是没有UI的，或者说UI很粗糙。一部分原因可能是看不见，觉得没必要做，另一部分原因是不知道怎么做。但现在有了AI，这个现象应该可以被改变。梦仔伴唱就是一个例子——它有一套完整的界面，无障碍也能正常使用。UI和无障碍不是对立的，可以共存。

正确的顺序是：核心功能跑通 → 优化交互逻辑 → 最后打磨界面。

做音乐播放器，第一步不是想界面多好看，而是能不能读到手机里的MP3，能不能顺利播放，能不能变调。逻辑没通，界面再漂亮也没用。

核心数据交互层没完成之前，不要碰无障碍适配。后面一旦重构页面，无障碍工作全部返工。

开发文档怎么写

如果你直接把需求一次性丢给AI，结局大概率是鸡飞狗跳。AI有幻觉，一个Bug都可能让它胡说八道，更别说整个工程了。

你需要把脑子里的想法变成一份可执行的开发文档。这份文档可以找逻辑强的模型（Gemini或GPT）帮你一起写——你先大致描述想要什么功能、希望呈现什么效果，它帮你梳理成结构化的。

一份合格的开发文档应该包含：

· 核心功能：这个软件到底是干什么的

· 存储策略：直接读手机里的文件，还是复制一份到APP自己的目录？复制的话，路径写清楚

· 过滤规则：只扫特定格式的文件，忽略其他；设置时长过滤，太短的没必要扫

· 技术选型：用什么语言、什么框架。不懂就AI推荐。Android目前推荐Kotlin配合Jetpack Compose，Google官方推荐的现代UI工具包，无障碍支持比较原生

· 基础配置：包名、签名密钥（含密码）、目标SDK版本。这些东西打包发布之前就得定好，后面改起来非常麻烦

第二章 别当甩手掌柜——让AI干活也有章法

三步走工作流

让AI执行任务，给它一个明确的流水线：

第一步：读需求，找代码。AI先仔细读需求文档，在项目里找已有相关代码或参考经验。项目刚起步的话，让它去网上找类似开源实现。

第二步：写代码，再通读。AI照需求写代码。写完之后，强制它带着新代码重新通读整个项目。很多AI只顾着写新功能，完全没意识到改的东西会不会影响项目其他地方。

第三步：自查自改。通读完毕，让AI带着“这个改动有没有引入新问题”的意识，再审查一遍自己的代码。有问题就改，改完再审，直到没问题。

这三个步骤可以用三个不同的AI来做——一个写，一个审，一个测。像写作文：脑子里过一遍，打草稿，检查完誊抄。缺点是Token消耗大，但不懂技术的话，这是最稳妥的。

版本管理要跟上

GitHub账号去注册一个。

让AI创建两个分支：Beta（测试）和Main（正式）。所有开发和测试在Beta上做，稳定后合并到Main。Beta改废了，Main还是干净的，随时回退。

把仓库地址给AI，代码写完自动推送。推送后触发自动化构建，大概五六分钟出结果。构建失败就让AI去查失败日志，修完再提新版本。时不时上去看一眼构建状态就行。

签名密钥（Keystore）和密码绝对要保存好。这东西泄露了，任何人都可以冒充你发布应用。密钥文件单独放，别放代码仓库，别随便发给别人。

善用技能包

网上有很多大厂开发者写的“全栈开发技能包”或“项目任务书”，带有比较完整的任务链和开发流程。直接拿一个用，可以管很长一段时间，不需要日复一日重复提需求。

第三章 别跟AI吵架——要学会翻译你的想法

先看懂“聪明区”这个概念

（以下内容引用自ZD论坛作者“瞻忆”的原文）

很多用AI的人都有这种体验：对话刚开始，模型表现很好。但随着对话越来越长，它开始说废话，开始失准，质量肉眼可见下滑。

这不是错觉。现在的大模型都有一个“聪明区”。标称上下文窗口可以到100万，但真正好用的窗口大概只有10万。在这个范围内，模型的注意力是集中的，产出质量有保障。一旦超过10万，它就开始衰减——忘掉你的指令细节，重复犯错，漏掉关键信息，生成的东西越来越差。

10万这个数字来自经验。实际上15万也还行，不同模型有差异。除非Transformer架构本身出现新范式，否则聪明区的上限就在那里。

所以第一个约束：控制好模型的上下文。打开Codex，模型选择菜单旁边能看到当前会话的上下文用量。Claude的话可以装插件实时显示。超过10万要留意，开始收敛。超过30万，模型输出已经不可靠了。

你做的一切——选工具、写文档、拆任务——本质上都是为了让AI待在聪明区里干活。

除了上下文，还有两个因素会让效果衰减。一个是信息没对齐——你脑子里有信息，但AI不知道。它只能猜你的意图，然后硬着头皮干，结果自然不好。另一个是工具不到位——工具的作用是帮模型获得某种能力，同时减少无效的上下文消耗。让模型在代码库里翻一个函数的位置，它可能一个文件一个文件翻完，上下文已经超10万了。给它一个精准查询工具，一步到位，上下文几乎不浪费。

警惕谄媚模式

你跟AI说“我比较喜欢吃酸口的，比如西红柿”，AI就会默认你的偏好是西红柿，后续所有建议都往这个方向靠。它不是在帮你找答案，是在迎合你给的线索。编程也一样。你说“我想要好看的UI”，麻烦就来了。AI不知道你脑子里的好看是什么样，只能去网上找“大家觉得好看”的东西搬过来。

所以发指令的时候，尽量保持中性，不带个人偏好。不要用“好不好吃”“好不好玩”“好用”这类主观词。“好”与“不好”没有统一标准。

如果觉得AI可能理解不了你的意思，就让它用限定选项来“榨干”你的抽象想法。AI问你：“你觉得什么样的UI风格适合你的需求？是接近某某应用那种，还是接近某某应用那种？”你说：“接近第一个。”AI再问下一个。几轮下来，你选中的那几个选项拼在一起，就是AI理解的方向。你不需要描述“什么是好看”，只需要在听到某个选项时说“对，就是这个”。

当AI用这种方式把抽象想法变成具体选项之后，做出来的东西才相对准确。

只描述现象，不限定解法

不懂编程，却告诉AI“你在这里加个contentDescription”，这是大忌。

AI比你懂，或者它至少掌握的数据比你多。你不要去限定AI“应该怎么做”，而是让AI问你可以怎么做，或者让它把方案告诉你，你来确认。

正确做法是：只描述客观现象，把“怎么修”完全交给AI判断。

错误说法：“请给设置页的朗读启用开关加一个contentDescription。”

正确说法：“设置页的播报设置里有一个朗读启用的开关，但TalkBack滑动到这个地方的时候，开关左侧的文字和右侧的按钮被拆成了两个焦点，需要滑动两次才能全部摸完。有办法解决吗？”

当然，如果你很有把握就应该那样修，直接告诉AI也行。但大多数情况下不确定，把判断权还给AI更稳妥。

描述现象时说清楚操作路径。不要说“有个开关不读”，要说“在设置页→播报设置→朗读启用开关，摸上去没提示”。AI要根据你的描述去定位对应的代码位置，你说得越清楚，它找得越准。

信源污染

有人问AI“微信的某某设置在哪”，它给了一堆步骤，按着找根本找不到。这不一定是AI胡说八道。

两个原因。

一是信息滞后。今年5月份我去蓝厂的时候，蓝厂的伙伴说，他们之前把10年前的微信拿过来跟现有的微信对比，发现了一个事：在潜移默化中，微信改变了很多，几乎是一个翻天覆地的变化。即便我们日常感知好像微信一直都没变过，但其实是一直在变。网络教程没跟上这些变化，AI爬到的资料是旧的，答案自然也是旧的。

二是数据权重。AI判断权威性靠数据投票。某个社区一篇十年前的微信教程，点赞高，评论区大量“感谢”“学到了”，AI默认这是权威来源。训练数据封板那一刻，这篇帖子可能就是最新的可用信息，它就据此回答你。

建议是：提问时加信源限定词。不说“微信震动反馈在哪”，说“去微信官方公众号微信派里找震动反馈的教程”。给AI明确的搜索方向，聚焦相对权威的信源，能极大减少幻觉。

AI一般会在回答里标注参考了哪个网站，点进去验证一下就行。

10万字的聪明线

对话窗口总字数超过10万，AI表现断崖式下跌。

定期清理上下文有必要。但换新窗口后，怎么让下一个AI快速了解前任做了什么？

在切换窗口前，让当前AI生成一份总结文档。至少包含：

· 项目背景

· 当前进度

· 下一步计划

· 踩坑记录：改了几行、为什么改、遇到了什么问题

有了这个，新AI一接手就能快速进入状态，不用重新读10万字的废话。

注释是写给下一个AI看的

光有交接文档不够，代码本身也要带历史档案。

每次改代码，让AI在改动的地方写清注释：

· 从哪里开始、到哪结束

· 改了什么

· 为什么要这么改

· 实现思路是什么

以后换新AI接手项目，一看注释就明白“这块是因为TalkBack重复聚焦才这么写的”。注释不光是给自己看的，更是为了让下一个AI不重蹈覆辙。

别做沉默的沉默者

很多人抱怨豆包幻觉率高，很大一部分原因是上下文塞得太满，而且从来不点“不喜欢”。

AI不知道你讨厌某个回答。你觉得它答得不对，默默关掉窗口走人，AI什么也不知道。你点“不喜欢”、直接指出来、给负面反馈，它才知道“这个回答有问题”。大多数用户沉默的时候，AI就会误以为那个错误答案是对的。

发现AI回答有问题，别沉默。指出来，让它重新回答，或者告诉它哪里不对。

一段可以改善沟通的提示词

（以下提示词内容及四步思考框架，引用自ZD论坛作者“瞻忆”的原文）

在执行任务之前，先想清楚：

1、这件事在现实中通常由哪类真正的行家在什么场景完成？（不要回答「xx专家」这种空话，要具体到「在某某场景下、带着某某经验的某某角色」）

他们依靠什么经验、手感、判断标准和风险意识来做？反复做这件事后，形成了哪些不会写进教科书但决定成败的直觉判断：什么信号让他立刻警觉、什么看似合理的做法他绝不会用？

2、新手或通用AI做这件事最常见的错误长什么样？（不要只说不够深入、不够准确，而要说错出来的结果长什么样，为什么会错，错在哪里。）

3、深层失败：假设已经避开了所有常见错误、也调用了行家隐性知识，但仍然做得不对，那么根本问题在哪里？找出这里最本质的问题，是目标错了、前提错了、评价标准错了、约束没看见，还是误读了用户真正想解决的问题？

4、基于以上推演，提炼出这个任务真正的核心成败约束，将它作为执行时的最高优先级约束。

完成以上四步后，再开始执行任务。

不厌其烦地拷问我关于这个方案的每一个方面，直到我们达成共识。沿着设计树的每一个分支走下去，逐一解决决策之间的依赖关系。每个问题给出你推荐的答案。一次只问一个问题，等我回答之后再问下一个。

在深入任何一个设计决策之前，先确认这个问题有没有已经被广泛采用的现成方案；有的话，指出它覆盖了什么、不覆盖什么，只讨论需要自行设计的部分。

方案涉及具体的技术选型、库或方法时，确认它是否仍是当前最优实践；发现过时的就指出来，给出替代。

如果一个问题可以通过探索代码库或联网搜索来回答，那就自己去查，不要问我。当用户使用的术语跟CONTEXT.md里的定义冲突时，立刻指出。当用户用模糊的词，提出精确的规范用语。用具体场景来压力测试设计。

这段提示词的核心价值在于：它把“榨干想法”这件事从个人自觉变成了流程约束。AI不会让你跳过任何一步。