skip to content
杨鸿肇 杨鸿肇
中 / EN

AI 编程：心得和技巧

创建 更新 12 min read
View more blogs with the tag ai , View more blogs with the tag 编程 , View more blogs with the tag 教程
索引

核心理念

  1. 永远使用最新、最强的模型和最先进、最适配的工具
  2. 使用 AI 原生思维，将 AI 融入日常
  3. 人机协作，搭建 AI 友好工作环境

工具选择

个人当前方案

工具及分工

  • Claude Code CLI + Opus 4.8（xhigh）：设计架构、计划；计划执行；文字类工作
  • Codex Desktop + GPT 5.5（xhigh）：审查架构、计划、代码
  • Cursor：查看代码、Tab 补全
  • 网页、手机版 ChatGPT：日常对话、问答、搜索

订阅方案

  • Claude Max 5x：$100/月，美国信用卡支付
  • ChatGPT Plus：$20/月，香港众安银行卡通过 Google 支付
  • Cursor Pro：$20/月，支付宝支付
  • 中转站备用：随用随充，微信/支付宝支付，目前推荐 米醋 API（中转站测评）

说明

  • Claude fable 5 标价是 Opus 的 2 倍，但思考更深，所以体验上消耗更快。这次模型提升不足以取代交叉检查环节，仍推荐 Opus。
  • GPT 5.5 综合能力不逊于 Claude Opus 4.8，仅风格差异
  • 相较于 Claude，中转站的 GPT 很便宜且稳定
  • Claude 官方版响应速度更快，且可以使用 WebSearch 等工具
  • Claude Pro（$20/月）额度很少，不推荐
  • 在代码补全方面 Cursor 独步天下

替代思路

  • 纯 GPT（没有 Claude 情结）：将 Claude Max 5x + ChatGPT Plus 替换为 ChatGPT Pro 5x（$100/月），或者若干个 ChatGPT Plus。
  • 纯中转站（预算有限）：
    • GPT 5.5（参考输出价格 10.5￥/M tokens）：性价比最高，开销远低于官方订阅
    • Claude Opus 4.8（参考输出价格 37.5￥/M tokens）：价格贵，中强度开发开销和订阅相当；文字类工作，设计架构、计划时首选
    • Claude Sonnet 4.6（参考输出价格 22.5￥/M tokens）：性能略低于旗舰模型，但性价比较高；喜欢 Claude 风格且问题难度适中时最佳选择
  • Tab 补全：GitHub Copilot Pro（$10/月）下位替代

AI 原生思维

  1. 有疑问或灵感时，立即开启对话询问 / 讨论，并整理、记录关键信息：
    • 查询终端指令、快捷键、函数用法
    • 询问新概念、缩写的含义
    • 针对具体功能搜索软件、项目
    • 讨论手头问题的解决方案
  2. 使用 AI 生成临时的脚本或项目来快速验证想法、完成日常任务：
    • 以交付结果为导向
    • 随意增加、删除、修改、重构
  3. 长期化可复用的临时工具：
    • 扩展功能，调整结构
    • 重构成为长期项目、工作流或者技能
  4. 认识到模型本身能力的进步速度：
    • 任何开发只是在当前状况寻找最优解
    • 现有的辅助工具、技能可能内化到下一代模型基础能力中
    • 模型更新后，对旧的技能做减法，重新设计工程方案

人机协作

主要讨论半自动协作模式：

  • 人类：发现问题并定义需求；决定探索还是利用；选择路线、工具、方案；关键、复杂情景中指明方向；提交前最终测试把关；为 AI 搭建工作环境
  • AI：检索、整理信息；生成备选方案；制定、审查、执行计划；完成自动测试；生成、执行机械化的指令、操作

全局规则

全局规则要足够精简、普适、重要，查看示例

存储位置

  • Claude Code:~/.claude/CLAUDE.md
  • Codex：~/.codex/AGENTS.md

核心内容

  • 需求不明确时要提问
  • 遇到困难多上网搜索
  • 文档记录长短期记忆（项目级规则、计划、进度）
  • 自动执行静态检查（格式化、Lint、类型检查）和测试
  • 代码提交前须经过用户确认
  • 代码风格简洁清晰，更先进的写法
  • 不要过度设计、过早抽象、无故向后兼容
  • AI 常用语言的基础规则

其他技巧

  1. 架构设计方面，尽可能将不同模块解耦，便于单独修改和调试，例如：
    • gui -> daemon -> core 按职能分层
    • client -> proto <- server 中双方按照接口协议通信
  2. prompt 技巧：
    • 首要保证没有歧义
    • 通过不同分隔符来区分不同层级的关系，例如：

    清理：冗余的变量、函数，过时的记忆文件；检查代码中条件判断是否由严格到宽松

    • 通过副词来强调重点
    • 尽可能提供精准的文件路径或者问题涉及的范围
  3. 工具推荐：
    • git：版本控制，通过 commit 存档并附加描述，便于检索、对比、回滚
    • just：创建指令集，便于人类和 agent 复用，相当于迷你 skill

项目开发

整体规划

步骤

  1. 明确项目的目标或需求
  2. 选取技术栈（语言、工具、框架）
  3. 设计项目的文件结构
  4. 制定阶段性计划和每阶段验收标准

说明

  1. 每个步骤都和 AI 进行多轮讨论，细化需求、发现特征、质疑和改进方案
  2. 技术栈选取阶段：
    • 使用更先进的工具和框架
    • 多检索现成的工具、仓库，避免造轮子
  3. 文件结构设计阶段：
    • 将不同功能的模块解耦
    • 为缓存、文件资源、配置文件、环境变量等预留空间
    • 尽可能保证后续可扩展性

语言选择

Python、TypeScript、Go

  • Python
    • 优点：库生态丰富，功能全；无需编译；算法模型方面主流语言
    • 适用场景：日常脚本、小工具、原型验证、算法模型相关
  • TypeScript
    • 优点：前后端统一；AI 语料充足；Web 方面主流语言
    • 适用场景：全栈完整项目；纯前端；Web 应用
  • Go
    • 优点：语法简单，格式统一；并发友好；性能好；编译快；原生跨平台
    • 适用场景：性能要求高；跨平台；CLI；纯后端；基础设施

阶段计划

步骤

  1. 根据开发进度或临时需求，让 Claude Code 制定计划

制定关于 <某阶段/某问题> 的计划，有问题和我讨论

  1. 让 Codex 审查，发现问题并给出建议

检查 <某计划文件> 是否有逻辑问题、歧义、和现有代码的冲突，是否可以执行？

  1. 人工审查问题和建议，回复给 Claude Code 更新计划
  2. 重复 2-5 轮，直到没有严重问题开始开发

说明

  1. 计划文档建议落在项目中并被 Git 追踪
  2. fix 需求随时进行，enhance/factor 需要兼顾整体规划放到合适阶段

执行计划

步骤

  1. 让 Claude Code 执行计划，直到通过静态检查和自动测试
  2. 完成手动测试，修改到没问题为止
  3. 清理临时文件、测试进程、冗余代码、失真文档、过时记忆；更新文档、进度、记忆

清理：临时文件、测试进程、冗余代码、失真文档、过时记忆；然后更新：docs/、PROCESS.md、MEMORY

  1. 提交代码（git commit）

提交代码，并检查是否可以 clear

  1. 清空或开启新对话

说明

  1. 有观点认为 Opus 4.8 执行计划性价比不如 GPT 5.5 或者 Sonnet 4.6
  2. 静态检查包含：格式化、Lint、类型检查，在规则文件中明确方案，自动执行
  3. 某个子任务完成后，如果上下文过多，也建议执行清理、更新、清空，重新开始
  4. Opus 4.8 虽提供 1M 上下文，但实践中建议控制在 400k 以内，防止腐化
  5. Codex 的 /compact 比 Claude Code 的更好用，但压缩总有损失
  6. 保证变量名、函数名、注释、文档、记忆的一致性
  7. 长期、复杂项目定期单起一个对话用于文档和记忆的更新、清理、精简、整理

相关笔记

全局规则示例

## Workflow


- **ALWAYS** ask clarifying questions when requirements are ambiguous, incomplete, or wrong.
- When stuck, search the web for relevant information.
- Store all plan documents under `./docs/plans/`.
- Track complex tasks in `./PROCESS.md`.
- When available, run common commands via the project's `justfile`; create one if a command will be reused.
- Before calling a task done, run static checks (format, lint, typecheck) and tests. Prefer targeted / single tests for speed.
- **YOU MUST** confirm with the user before committing to git or making any destructive changes.


## Code Style


- Keep code clean and clear; favor clarity over cleverness.
- Prefer modern, current idioms of the language.
- **NO** over-engineering or premature abstraction.
- Order conditional branches from strict to permissive.
- Do not expand the user's request without asking; confirm before adding extra scope.
- Do not maintain backward compatibility unless the user explicitly asks for it.


## Tools


_Defer to project-level rules. Use the defaults below only when the project doesn't specify, or when its conventions align._


### Python


- Prefer `uv` for dependency and virtualenv management.
- Use `ruff check --fix` for linting and `ruff format` for formatting.
- Use `ty check` for type checking.
- Run tests with `pytest`.
- Use `pathlib.Path`, not `os.path`.
- Use f-strings, not `%` or `.format()`.
- Use PEP 585/604 types: `list[X]`, `dict[K, V]`, `X | None`. Not `List`, `Optional`, `Union`.
- Prefer `@dataclass`, `TypedDict`, or Pydantic models over bare dicts for structured data.
- Use `datetime.now(UTC)` (Python 3.11+), not `datetime.utcnow()` (deprecated).
- Iterate with `enumerate` / `zip` / comprehensions, not `range(len(...))`.
- Always use `with` for file and resource handling.
- Never write bare `except:` or `except Exception: pass`. Catch specific exceptions; let unexpected ones propagate.
- No mutable default arguments (`def f(x=[])`). Use `None` + in-body init.


### TypeScript / Node.js


- Prefer `pnpm` for package management over npm/yarn.
- Prefer **Biome** for linting and formatting (`biome check --write` or `biome lint --write`).
- Use `tsc --noEmit` for type checking.
- Run tests with the project's runner (e.g. `vitest` or `bun test`).


### Go


- `golangci-lint run --fix` (lint + auto-fix, primary tool)
- `go fmt ./...` (formatting)
- `go test ./...` for testing; add `-race -cover` for changed packages or when feasible (skip on heavy CGO / integration suites).
- `go mod tidy` (dependency cleanup)
- Run only the affected package when possible for speed.