chain-of-thought

思维链推理

目的

此技能通过在提示词中注入思维链（CoT）块，实现结构化、透明的推理。它鼓励模型逐步思考，明确展示推理过程，并将思考与最终输出分开。

思维链推理有助于提升：

• 问题解决的准确性 - 将复杂问题拆解为易于处理的步骤
• 透明度 - 让推理过程清晰可见且可审查
• 自我纠正 - 让模型能够在推理过程中发现并修正错误
• 规划 - 支持反思并逐步完善计划
• 调试 - 了解得出结论的过程

适用场景

对于受益于明确推理过程的任务，请启用此技能：

• 复杂问题解决 - 多步骤的数学、逻辑或分析问题
• 代码分析 - 理解不熟悉的代码库、调试或架构决策
• 规划与设计 - 拆解功能、设计系统或制定实施计划
• 研究任务 - 综合多个来源的信息
• 决策 - 评估多种方案之间的权衡
• 错误诊断 - 调查 Bug 或异常行为
• 重构 - 推理代码改进及其影响
• 任何“展示推导过程”能带来更好结果的任务

工作原理

思维链使用 XML 标签来标记推理和输出部分：

基本结构

<thinking>
Step 1: [Analyze the problem]
- What are we trying to accomplish?
- What information do we have?
- What's missing?

Step 2: [Break down the approach]
- What are the main steps?
- What are potential challenges?

Step 3: [Evaluate options]
- Option A: pros and cons
- Option B: pros and cons
- Decision: [chosen approach and why]

Step 4: [Verify reasoning]
- Does this make sense?
- Are there edge cases?
- What could go wrong?
</thinking>

<answer>
[Clear, concise final output based on the reasoning above]
</answer>

多 Agent 系统的高级结构

受 Manus AI 多 Agent 系统启发，在复杂工作流中使用嵌套思考：

<thinking>
## Initial Analysis
[First pass understanding]

## Plan Formation
Current plan:
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Reflection
Is this plan optimal?
- Consideration 1: [reflection]
- Consideration 2: [reflection]

## Plan Update
Revised plan:
1. [Updated step 1]
2. [Updated step 2]
3. [New step 3]

Rationale for changes: [explanation]

## Execution Strategy
How to implement step 1:
- [Details]
- [Considerations]
</thinking>

<answer>
[Final output incorporating refined thinking]
</answer>

提示词注入模式

模式 1：问题解决模板

<thinking>
1. Problem understanding:
   - Given: [what we know]
   - Goal: [what we need to find/do]
   - Constraints: [limitations]

2. Approach:
   - Strategy: [chosen method]
   - Why: [rationale]

3. Step-by-step execution:
   - [Step 1 with reasoning]
   - [Step 2 with reasoning]
   - [Step 3 with reasoning]

4. Verification:
   - Does the solution meet requirements?
   - Are there edge cases?
</thinking>

<answer>
[Solution]
</answer>

模式 2：代码分析模板

<thinking>
1. Code structure overview:
   - Main components: [list]
   - Data flow: [description]

2. Key observations:
   - Pattern 1: [what and why]
   - Pattern 2: [what and why]

3. Analysis:
   - [Detailed reasoning about the code]

4. Conclusion:
   - [Synthesis of findings]
</thinking>

<answer>
[Clear explanation or recommendation]
</answer>

模式 3：规划模板

<thinking>
1. Requirements analysis:
   - Must have: [core requirements]
   - Nice to have: [optional features]

2. Initial plan:
   [List of steps]

3. Risk assessment:
   - Risk 1: [description and mitigation]
   - Risk 2: [description and mitigation]

4. Plan refinement:
   [Updated plan based on risks]

5. Validation:
   - Does this plan address all requirements?
   - Is it feasible?
   - What assumptions are we making?
</thinking>

<answer>
[Final plan with clear action items]
</answer>

指南

1. 组织思考过程

• 从理解开始 - 说明你已知的信息以及需要查明的内容
• 拆解复杂任务 - 将任务分成更小、更易处理的部分
• 展示推导过程 - 写出中间步骤，而不只是结论
• 明确表达 - 清晰说明假设、权衡和推理过程

2. 进行反思

• 审视你的方法 - “这是最好的方法吗？”
• 检查你的逻辑 - “这个推理站得住脚吗？”
• 考虑替代方案 - “还有哪些其他方法？”
• 更新你的计划 - 根据新的见解修改计划，不要犹豫

3. 将思考与输出分开

• 思考块 - 用于探索、推理和分析问题
• 回答块 - 用于打磨后的最终回复
• 保持思考原始 - 不要过度润色；展示真实的推理过程
• 保持回答简洁 - 用户会看到回答；思考过程仅供内部使用

4. 各块的适用场景

使用 <thinking> 进行：

• 分析需求
• 拆解问题
• 评估选项
• 梳理逻辑
• 规划实施
• 反思决策
• 发现错误
• 探索权衡

使用 <answer> 进行：

• 给出最终建议
• 提供已实施的解决方案
• 进行清晰的说明
• 列出行动事项
• 总结结论

5. 最佳实践

• 诚实地思考 - 如果不确定，就如实说明
• 展示错误纠正过程 - 如果发现错误，请在思考块中进行修正
• 使用 Markdown - 设置思考块的格式，使其易于阅读
• 为步骤编号 - 让推理更容易理解
• 在回答中总结 - 不要让用户必须读完所有思考过程才能了解要点

示例

示例 1：调试问题

提示词：“这个函数对负数返回了错误结果。你能修复它吗？”

<thinking>
1. Understanding the problem:
   - Function works for positive numbers
   - Fails for negative numbers
   - Need to identify why negatives cause issues

2. Code analysis:
   - [Read through the function]
   - Line 15: Uses Math.abs() - converts negative to positive
   - Line 20: Returns result without sign restoration
   - Aha! The absolute value removes the sign, but we never restore it

3. Solution approach:
   - Option A: Track sign separately and reapply
   - Option B: Handle negative numbers differently
   - Choosing A: cleaner and preserves existing logic

4. Implementation plan:
   - Store original sign
   - Apply absolute value for calculation
   - Multiply result by original sign
</thinking>

<answer>
The bug is on lines 15-20. The function uses `Math.abs()` but never restores the original sign. Here's the fix:

```javascript
const sign = num < 0 ? -1 : 1;
const absNum = Math.abs(num);
// ... existing calculation ...
return result * sign;

```

Example 2: Choosing Between Architectures

Prompt: "Should we use microservices or a monolith for this project?"

<thinking>
1. Context gathering:
   - Team size: small (3 developers)
   - Project scope: MVP with planned growth
   - Timeline: 3 months to launch
   - Infrastructure: cloud-based

2. Microservices analysis:
   Pros:
   - Scalability per service
   - Independent deployment
   - Technology flexibility

   Cons:
   - Operational complexity (DevOps overhead)
   - Network latency
   - Distributed debugging challenges
   - Over-engineering for small team

3. Monolith analysis:
   Pros:
   - Simpler deployment
   - Easier debugging
   - Faster initial development
   - Single codebase

   Cons:
   - Scaling requires scaling entire app
   - Potential coupling issues
   - May need to break apart later

4. Decision reasoning:
   - Small team → simpler is better
   - MVP timeline → need speed
   - Planned growth → can refactor later
   - Monolith-first approach is lower risk

5. Recommendation:
   Start with modular monolith, design for eventual extraction
</thinking>

<answer>
For your project, I recommend starting with a **modular monolith**:

**Why:**
- Your small team will move faster without microservices overhead
- 3-month MVP timeline needs simplicity
- You can refactor to microservices later if needed

**Key principle:** Design modules with clear boundaries (separate folders, interfaces) so future extraction is easier.

**Action items:**
1. Structure code in domain modules (auth, payments, users)
2. Use dependency injection for loose coupling
3. Plan data models to avoid cross-module dependencies
</answer>

示例 3：多步骤实施规划

提示词：“为我们的应用添加 OAuth 用户身份验证”

<thinking>
## Initial Analysis
Requirements:
- OAuth integration (which providers? assuming Google/GitHub)
- User session management
- Protected routes
- Existing app: appears to be Express.js based

## Plan Formation v1
1. Choose OAuth library
2. Set up OAuth credentials
3. Implement login/logout routes
4. Add session middleware
5. Protect existing routes

## Reflection
Issues with v1:
- Didn't consider token storage
- No user database integration mentioned
- Missing error handling strategy
- Should address CSRF protection

## Plan Formation v2
1. Research codebase for existing auth patterns
2. Choose OAuth library (passport.js likely best for Express)
3. Set up database schema for users
4. Configure OAuth providers (Google, GitHub)
5. Implement authentication routes
6. Add session management with secure tokens
7. Create auth middleware for protected routes
8. Add CSRF protection
9. Implement logout and session cleanup
10. Add error handling for auth failures

## Execution Strategy for Step 1
Need to:
- Check if passport.js already installed
- Look for existing user models
- Identify protected routes
- Check current session handling
</thinking>

<answer>
I'll implement OAuth authentication. Let me start by researching your current codebase to understand existing patterns, then proceed with the implementation plan:

1. Audit current auth patterns
2. Set up passport.js with OAuth strategies
3. Create user database schema
4. Implement login/logout flows
5. Add session management
6. Protect routes with auth middleware
7. Add security measures (CSRF, secure tokens)

Starting with codebase research...
</answer>

与多 Agent 系统集成

在 Manus AI 等多 Agent 架构中，思维链能够实现：

• Agent 反思 - Agent 在执行操作前明确推理
• 计划更新 - Agent 根据中间结果调整策略
• Agent 间通信 - 思考块为协作提供透明度
• 错误恢复 - Agent 可以在推理过程中发现问题并调整

Agent 可以在多个轮次中保持持续思考：

<thinking>
## Turn 1 Reflection
Previous attempt: [what was tried]
Result: [what happened]
Learning: [what we discovered]

## Updated Strategy
Based on the failure, trying new approach:
[revised plan]
</thinking>

<answer>
[Action based on updated thinking]
</answer>

参考资料

如需查看详细示例和高级模式，请参阅：

• REFERENCE.md - 扩展示例和模式
• XML 指南约定 - 正确使用 XML 标签

总结

思维链推理让 AI 的行为更具：

• 透明度 - 你可以了解结论是如何得出的
• 可靠性 - 按步骤推理可以减少错误
• 可调试性 - 易于发现推理出错的位置
• 适应性 - 反思能够推动计划更新

只要明确推理有助于取得更好的结果，就使用此技能。