知识索引

容量、速度和角色是不同的事。磁盘空余很多，不代表运行程序时内存也充足。

描述故障时先说清：停在哪一屏、出现什么文字、之前做过什么。

向 AI 询问操作步骤时，先交代你的操作系统；文件与正在运行的进程不要混为一谈。

“看到了变化”和“保存了变化”是两件需要分别验证的事。

先记录何时出现、影响哪些程序、什么动作能改善，再讨论原因。

先说清输入和期待的结果，再讨论用什么代码实现。

语言是实现选择，目标和运行环境应当先明确。

代码的行为可以用具体输入来推演，不必靠猜。

让 AI 说明数据长什么样，往往比先解释每行语法更容易理解程序。

运行问题至少提供：系统、项目目录、命令和完整错误。

AI 写完不等于任务完成。运行、检查差异和验证结果仍然属于编程。

网络程序需要考虑等待、失败和重试，不仅是成功路径。

先区分本地网络与其他网络，不必把每个协议细节一次记住。

描述访问问题时，贴出完整地址和服务启动输出，保留端口。

“连上无线”只说明一部分连接已经建立。

讨论“能不能访问”时，先问从哪台设备、哪个网络访问。

提供完整网址，比只说“那个网站”更容易定位问题。

把问题拆成：发出了什么请求、收到了什么响应、界面怎样使用响应。

陈述观察与证据，把原因留给排查。

“我能打开”与“目标用户能使用”需要分别验收。

从需求倒推服务，不用把每种平台都接进第一版。

说“保存数据”时，还要说明位置、生命周期和谁能访问。

先画出数据字段和关系，再让 AI 选择合适的存储方案。

把筛选、修改和删除分清，是准确描述需求的一部分。

选数据库之前，先说明“有哪些数据、怎样关联、经常怎么查”。

性能优化需要测量；不要只凭“数据库慢”就堆新技术。

先明确单机遇到的限制，再讨论是否需要分布式。

评估并行方案时，同时考虑可拆分工作和协调开销。

如果数据重复被查询，先想能否提前整理或缓存，而不只是增加机器。

先提出要回答的问题，再决定记录什么事件。

把复杂度花在已确认的问题上。

模型的能力需要在实际任务和新例子上检验。

把神经网络当作可训练的计算结构，而不是一个小人脑。

理解 token 是处理单位即可，精确计数要使用对应模型的工具。

分清模型生成的说法与工具真正完成的动作。

关键约束明确提供，重要结果独立验证。

说明任务之前，先确定助手实际看得见和做得到什么。

用适合自己的任务评估模型，结果比宣传词更重要。

更多计算不能替代缺失信息和验收标准。

交接的目标是让接手者知道现状和下一步，而不是复述全部历史。

专业性来自明确的信息和可检查的结果，不来自堆砌术语。

先写出流程和输出标准，再决定工具。

先找数据来自哪里，再考虑怎样操作界面。

接口选择影响可靠性，也影响后续维护。

把提取结果当作需要验证的数据。

自动化也需要验收动作的结果，而不仅是记录动作发生过。

专业自动化同时说明成功路径、失败路径和重复执行时的行为。