作者一位Android开发工程师 | 2026年6月3日系列第5天已通过自测本篇拆解CoT思维链前言前面几天我们一直在调参数temperature、system prompt今天学一个不调参数也能大幅提升回答质量的技巧——Chain-of-Thought思维链。核心思想在问题后面加一句请一步一步推理LLM 会自动把问题拆成步骤每一步都验证后再输出结论。实验设计同一道 Android 模块依赖推理题调两次 API——一次不加 CoT一次加。问题有一个 Android 项目模块依赖关系如下 - app 依赖 core 和 feature-login - feature-login 依赖 core - core 依赖 common-util - feature-profile 依赖 core 和 common-util 问题如果 common-util 的 API 改了哪些模块需要重新编译第一次正常问第二次问题后面拼接\n\n请一步一步推理先列出每个模块的依赖链再分析影响范围。# 不加 CoTresponse_no_cotclient.chat.completions.create(modelturing/gpt-4o-mini,messages[{role:user,content:problem}],temperature0.7,)# 加 CoTresponse_cotclient.chat.completions.create(modelturing/gpt-4o-mini,messages[{role:user,content:problem\n\n请一步一步推理...}],)结果对比不加 CoT如果 common-util 的 API 改了以下模块需要重新编译 1. core直接依赖 common-util 2. feature-login依赖 core 3. feature-profile依赖 core 和 common-util 4. app依赖 core 和 feature-login平铺直叙枚举结论。读起来能懂但缺少推理过程。加 CoT### 模块依赖关系分析 1. app → core, feature-login 2. feature-login → core 3. core → common-util 4. feature-profile → core, common-util ### 依赖链总结 - app 依赖 core 和 feature-login - core 依赖 common-util - feature-login 依赖 core → 间接依赖 common-util - feature-profile 依赖 core 和 common-util ### 影响范围 common-util 改变后 - core 直接受影响需重新编译 - feature-login 依赖 core间接受影响 - feature-profile 直接依赖 common-util - app 依赖以上所有模块 结论全部4个模块都需要重新编译。结构清晰三倍——依赖分析 → 链式推导 → 影响范围 → 最终结论。每一步都有依据。为什么有效LLM 本质上是下一个词预测器。不加 CoT 时它直接从问题跳到结论——中间可能跳错。加 CoT 后相当于在问题和结论之间插入了中间验证步骤。每一步的输出都约束了下一步的预测方向就像 Kotlin 里加了类型检查// 不加 CoT直接返回funanalyze():ListModule...// 加 CoT分步验证funanalyze():ListModule{valdepsbuildDependencyTree()// 步骤1valaffectedfindAffected(deps)// 步骤2returnaffected// 步骤3}今天的一句话总结CoT 就是在 prompt 后面加请一步一步推理——让 LLM 从直接给答案变成展示推导过程准确度和可读性都大幅提升。下一篇预告第7天第一阶段综合实战——把前6天的技能融进一个 Kotlin 代码审查工具。本系列记录一位Android开发者转行AI Agent的完整学习过程欢迎关注交流。
Android开发转AI Agent:第6天——加一句话让LLM推理准确度翻倍
发布时间:2026/6/4 19:47:24
作者一位Android开发工程师 | 2026年6月3日系列第5天已通过自测本篇拆解CoT思维链前言前面几天我们一直在调参数temperature、system prompt今天学一个不调参数也能大幅提升回答质量的技巧——Chain-of-Thought思维链。核心思想在问题后面加一句请一步一步推理LLM 会自动把问题拆成步骤每一步都验证后再输出结论。实验设计同一道 Android 模块依赖推理题调两次 API——一次不加 CoT一次加。问题有一个 Android 项目模块依赖关系如下 - app 依赖 core 和 feature-login - feature-login 依赖 core - core 依赖 common-util - feature-profile 依赖 core 和 common-util 问题如果 common-util 的 API 改了哪些模块需要重新编译第一次正常问第二次问题后面拼接\n\n请一步一步推理先列出每个模块的依赖链再分析影响范围。# 不加 CoTresponse_no_cotclient.chat.completions.create(modelturing/gpt-4o-mini,messages[{role:user,content:problem}],temperature0.7,)# 加 CoTresponse_cotclient.chat.completions.create(modelturing/gpt-4o-mini,messages[{role:user,content:problem\n\n请一步一步推理...}],)结果对比不加 CoT如果 common-util 的 API 改了以下模块需要重新编译 1. core直接依赖 common-util 2. feature-login依赖 core 3. feature-profile依赖 core 和 common-util 4. app依赖 core 和 feature-login平铺直叙枚举结论。读起来能懂但缺少推理过程。加 CoT### 模块依赖关系分析 1. app → core, feature-login 2. feature-login → core 3. core → common-util 4. feature-profile → core, common-util ### 依赖链总结 - app 依赖 core 和 feature-login - core 依赖 common-util - feature-login 依赖 core → 间接依赖 common-util - feature-profile 依赖 core 和 common-util ### 影响范围 common-util 改变后 - core 直接受影响需重新编译 - feature-login 依赖 core间接受影响 - feature-profile 直接依赖 common-util - app 依赖以上所有模块 结论全部4个模块都需要重新编译。结构清晰三倍——依赖分析 → 链式推导 → 影响范围 → 最终结论。每一步都有依据。为什么有效LLM 本质上是下一个词预测器。不加 CoT 时它直接从问题跳到结论——中间可能跳错。加 CoT 后相当于在问题和结论之间插入了中间验证步骤。每一步的输出都约束了下一步的预测方向就像 Kotlin 里加了类型检查// 不加 CoT直接返回funanalyze():ListModule...// 加 CoT分步验证funanalyze():ListModule{valdepsbuildDependencyTree()// 步骤1valaffectedfindAffected(deps)// 步骤2returnaffected// 步骤3}今天的一句话总结CoT 就是在 prompt 后面加请一步一步推理——让 LLM 从直接给答案变成展示推导过程准确度和可读性都大幅提升。下一篇预告第7天第一阶段综合实战——把前6天的技能融进一个 Kotlin 代码审查工具。本系列记录一位Android开发者转行AI Agent的完整学习过程欢迎关注交流。