AI 编程的思考方式：从快思考到架构设计

前言

最近整理了一些笔记，发现几条主线：LLM 工具选择、认知科学启发、以及 AI 编程的局限性。这篇文章将它们串联起来，形成一个完整的思考框架。

一、CLI Agentic Coding Tool 选型

经过调研和实际使用，总结主流 CLI 编程工具的模型排名：

关键发现：

• Aider + DeepSeek V3 是高性价比组合
• 模型对搜索信息的依赖度决定了回答质量
• 国外模型在数据广度上有明显优势

二、编程的瓶颈：需求描述

Coding 的瓶颈是，我怎么准确清楚地描述需求为 LLM 理解的语言。

这是一个深刻的洞察。LLM 再强大，如果需求描述不清晰，产出的代码也会偏离预期。

解决方案：

1. 先设计，后编码 — 架构确定后再用 AI
2. 分解问题 — 将大需求拆解为小步骤
3. 提供上下文 — 代码库结构、依赖关系、技术约束

三、AI 编程的局限性

一开始他们也试过偷懒，直接扔一句"这是功能需求，这是相关文件，你去实现"。结果代码能跑，但歪得厉害，完全不符合架构预期。

这是 Vibe Coding 的典型问题：

• 优点：快速验证想法，适合原型
• 缺点：缺乏抽象，重复代码多，硬编码泛滥
• 后果：后期维护成本指数级上升

正确的使用方式

AI 辅助开发流程：
1. 脚手架构建（自己动手，定好架构）
2. 核心模型设计（明确数据结构）
3. 小函数/组件（用 Vibe Coding）
4. 人工审核（必须有人把关）

核心原则：

• 架构设计必须内化
• 克制复杂性，复杂性是 MVP 的敌人
• 但也要考虑架构设计，避免技术债

四、UI 与数据的关系

UI 只是数据的投影，数据才是本质。

这个观点让我重新思考前端开发：

1. 数据驱动 UI — 先定义数据结构，再考虑展示
2. UI 分析方法 — 看到 UI 时，先思考它映射了哪些数据
3. AI 辅助 — 让 AI 理解数据结构，它能更好地生成 UI 代码

五、认知科学启发：系统 1 与系统 2

"写下来"不仅仅是记录，而是思考本身。语言不是思维的包装，语言就是思维的脚手架。

这对应了丹尼尔·卡尼曼《思考，快与慢》的核心观点：

关键启示：

• 编程时我们经常在"该用系统 2"的时候偷懒用了"系统 1"
• 写文档时要考虑 AI 读取，要结构化、清晰
• 面对复杂问题，强制自己"写下来"能启动系统 2

六、技术选型：多语言 AI SDK 对比

如果要用 Java/Node/Python 做 AI Agent 开发，以下是主流选择：

选型建议：

• Java 选 Spring AI Alibaba（服务发现、自动扫描）
• Node 选 NestJS MCP（依赖注入、类型安全）
• Python 选 FastMCP（Sampling 易用）

七、Prompt 工程：Few-shot 学习

在实际应用中，用户可以通过 Few-shot 学习的方式，来提升模型的输出效果。

Few-shot 的优势：

• 提供示例，让模型学习特定模式
• 相同上下文前缀可缓存，费用显著降低
• 适合质检、分类等重复性任务

应用场景：

• 客服质检（判断是否文明用语、话术标准）
• 代码审查（检查是否符合规范）
• 内容分类（情感分析、意图识别）

总结

AI 时代的编程，不是用 AI 替代程序员，而是：

1. 冻结基座 — 现有知识足够，先别焦虑地学更多
2. 疯狂推理 — 行动起来，用起来
3. 反思优化 — 每天评估：这个让我更好了吗？
4. 修正目标 — 在行动中发现真正想要什么

最后一句话：

克制。能减少复杂性就减少复杂性。