范式转变
最开始，我们仅能使用 AI 做函数生成，tab 补全等非常基础的编程辅助。那时候，只有 VSCode Copilot，那时候，很多人还看不起 AI 编程。
Deepseek 带来的开源思维链也仅仅是今年春节才爆火起来。 时间没过多久，思维链、工具调用、Agent、超长上下文一个接一个出现，Claude 3.7 出现之后，AI 编程范式似乎一夜间就改变了。
本来他充其量只是个助手，现在起码是能干活的中级工程师。项目搭建、组件重构，指挥得当他都能完成。而且现在重构试错成本巨低，以前做一次重构发现效果不太好，代码都舍不得删，现在好了，半天够换着方法重构好几遍了。
Andrej Karpathy 创造了 Vibe Coding（氛围编程）这个词。他本人通过不断接受 AI 建议（“我总是接受所有建议，我不再阅读差异”），将错误信息复制粘贴给 AI，快速构建 Web 应用。在最近 AI IDE 井喷之后，大家应该或多或少都能意识到 Vibe Coding 是真的可行的。
Augment 是现在最好用的 AI IDE 插件，其中 Context Engine 和 Diagnostics 是两个非常强大的功能。
Claude Code
提示词工程
Garbage in, garbage out
AI 发展至今，提示词工程的效果逐渐弱化，AI IDE 和插件本身就自带好几千字甚至上万字的系统提示词，有时候自己附加提示词他甚至会无视（例如你很难让 Augment 不要写测试、文档，他总会自动写）。
角色扮演和思维链之类的提示词效果已经不明显，进入玄学的提升范畴。在 IDE 里现在比较好用的提示词应该基本只剩单样本和少样本提示词 (One-Shot & Few-Shot)。
还有一个流派是给 IDE 设定一堆 Rule 提示词。
又或者 Kiro 搞的那套：
- 阶段 1：需求澄清，将模糊想法转化为结构化需求文档
- 阶段 2：设计与研究，基于需求开发综合设计方案
- 阶段 3：任务规划，基于需求和设计创建可执行的实施计划
- 阶段 4：任务执行，按照SPECS文档执行实施任务
https://github.com/heihuzicity-tech/ClaudeCode-Kiro-Workflow
我曾经做过一次完整的流程，检查需求文档耗费精力，做一堆任务耗费时间也耗费 Token，结果没有特别好。kiro 自动生成的 task，最后几步可能会搞些看起来很高级的优化，但实则不推荐，本着能用就行的原则，一路上只要你觉得代码符合你的审美，最后的优化可能是过度优化。
主动提供上下文
传统的提示词的功能弱化后，用户主动提供的上下文会更重要。未来上下文工程可能会发展得更完美，但现在还是处于比较初级的阶段，下面介绍一些我平时会用的上下文获取方法。
UI 实现
对于多模态模型，图片是上下文的一部分，使用图片实现 UI 是很基础的操作。
现阶段要做到像素级的还原度，是不可能的，不过有一些值得注意的点，可以稍微提高生成质量。
使用图片时，可以先让 AI 描述图片内元素的基本布局，甚至引导它描述部分细节，如果它一开始就描述不准确，那后面就不用期待它能写对了。
为自己的代码库生成一个组件列表，让 AI 在从图片实现页面时在里面挑组件，必要时还是要主动告诉它需要什么已经抽象过的组件，因为光看名字很可能看不出来。
v0 是一个超强的截图转代码工具，还原度比直接用 Claude 高非常多。
修复 problem
[ { "resource": "/d:/gpu/src/pages/ResourceManagement/TeamResourceManagement.tsx", "owner": "_generated_diagnostic_collection_name_#4", "code": { "value": "lint/style/useImportType", "target": { "$mid": 1, "path": "/linter/rules/use-import-type", "scheme": "https", "authority": "biomejs.dev" } }, "severity": 8, "message": "All these imports are only used as types.", "source": "biome", "startLineNumber": 35, "startColumn": 8, "endLineNumber": 35, "endColumn": 26, "origin": "extHost1" }]Apifox 复制
可以在 Apifox 直接复制接口的 OpenAPI 规范，贴进去让 AI 加 api 十分方便且可靠。
openapi: 3.0.1info: title: "" description: "" version: 1.0.0paths: /api/v1/team/app/list: get: summary: list team app deprecated: false description: "" tags: - Team parameters: - name: teamId in: query description: "" required: true schema: format: int type: integer - name: page in: query description: "" required: false schema: default: 1 format: int type: integer - name: size in: query description: "" required: false schema: default: 10 format: int type: integer - name: Authorization in: header description: "" example: Bearer {{Authorization}} schema: type: string default: Bearer {{Authorization}} responses: "200": description: "" content: application/json: schema: $ref: "#/components/schemas/mlops.api.team.v1.ListTeamAppRes" description: "" headers: {} x-apifox-name: 成功 security: [] x-apifox-folder: Team x-apifox-status: released x-run-in-apifox: https://app.apifox.com/web/project/6423715/apis/api-326223640-runcomponents: schemas: mlops.api.team.v1.ListTeamAppRes: properties: apps: format: "[]*dto.App" items: $ref: "#/components/schemas/mlops.internal.model.dto.App" description: "" type: array type: object x-apifox-orders: - apps x-apifox-ignore-properties: [] x-apifox-folder: "" mlops.internal.model.dto.App: properties: id: format: int type: integer name: format: string type: string cmdbId: format: string type: string type: object x-apifox-orders: - id - name - cmdbId x-apifox-ignore-properties: [] x-apifox-folder: "" securitySchemes: {}security: []附带最佳实践
多数解现象是指 AI 模型倾向于生成训练素材中最常见、最直接的解决方案。换言之，训练素材只能反映那个语言的平均编码能力。尤其是 react，react 的思维负担是非常重的，这是框架本身的问题，夹不住素材实在多，所以它总能写出“能跑”的代码，事实上一看很多严格的规则都会标红，很多实现不是最优解。
这可能导致 AI 的代码在通用场景下正确，但在特定项目背景下并非最优，甚至，只是能用而完全不优雅，而且放任 AI 多数解也可能造成代码膨胀。
因为多数解现象，开发者必须识别这些潜在的假设和非最优选择，并根据实际需求进行调整。
在前端开发领域，由于门槛低，谁都能写，可能会导致一些代码质量问题，这些有问题的代码如果作为训练数据就会加重上述的多数解问题。所以作为前端开发，可能需要在上下文附加 React 最佳实践。
写 ChangeLog
获取上次发版的 git 提交哈希，跟 AI 说从根据这个哈希的提交开始到最新的提交生成 ChangeLog。他就会自动通过 git 命令收集需要的信息给你输出。
给一个模板可以保证 ChangeLog 格式统一。
## v1.0.0 (2025-01-15)
**功能描述 - 简短的版本亮点描述****代号: 项目代号**
### ✨ 新功能
- **核心功能增强** - 改进了应用程序的整体性能和稳定性- **更好的文件格式化** - 保存的文件现在具有适当的缩进以提高可读性
### 🔧 改进
- **更新的macOS图标** - 刷新应用程序图标以更好地集成macOS- **增强的性能** - 各种底层改进以获得更好的用户体验
### 🐛 修复
- **修复了登录问题** - 解决了某些情况下用户无法登录的问题- **修复了数据同步** - 改进了数据在设备间的同步稳定性
### 🚀 性能优化
- **启动速度提升** - 应用程序启动时间减少了30%- **内存使用优化** - 降低了内存占用，提高了运行效率
### 📚 文档更新
- **更新了用户手册** - 添加了新功能的详细说明- **API文档完善** - 补充了缺失的API接口文档
### ⚠️ 重大变更
- **API变更** - 某些API接口进行了重构，请查看迁移指南- **配置文件格式** - 配置文件格式有所变更，需要手动更新
---
**升级说明:**- 建议在升级前备份重要数据- 详细的升级指南请参考官方文档当然，前提是你的 commit message 要写得很标准。
DeepWiki
DeepWiki 是一个超赞的仓库 wiki 生成工具，只要你提供 GitHub 地址，它就能给这个仓库生成一个颇为完整的 wiki 页面。
同时，DeepWiki 提供 MCP 能力：
{ "mcpServers": { "deepwiki": { "serverUrl": "https://mcp.deepwiki.com/sse" } }}通过 ask_question 工具可以让你的 AI 工具向 Deepwiki 提问，如果你使用的某个冷门库文档没写好，或许可以直接用这个工具得到解决方案。
对于你自己写的项目，也可以 AI 生成文档，你审阅后没问题，这就能成为下次提问的上下文。
AI 编程模式
无限流
失败后，直接找到他的错误，然后直接更新提示词整个重试。例如你知道他会把问题复杂化，那就一开始就把简单的思路告诉他。
好处是不浪费上下文。另外，你可以知道 AI 的能力边界后补充上下文，例如你让他用一个库实现功能，但是他并不会用，那就需要补充文档链接。
Copy And Paste Great Again
类似的组件复制粘贴在前 AI 时代是一个大问题。当两个组件或函数有一点差异时，一般倾向于直接复制一份，而不是做抽象。但是后续修改时，要一一修改每一个地方，这不难，但是个体力活。
AI 时代来临后可以更放心地在初始开发时用复制粘贴这个模式。AI 可以找出类似内容批量修改，再也不需要做体力活。在后面如果真的有更多的使用情况，也可以后续再用 AI 做抽象。
毕竟过早优化是万恶之源，封装方法和组件越早，后面业务变更需要修改时就越畏手畏脚。
双向奔赴
在遇到你预感到 AI 不能或难以解决的难题时，交下任务同时可以自己再在 ChatGPT 上尝试寻找解决方案。这样也方便 AI 写完之后看懂它的实现方案。
上面提到的多数解现象出现时，我们就必须近一步指引 AI 重构，例如不要啥都写 useEffect，优先事件驱动之类的。
启动模板
使用 AI 需要有选型能力，仅从前端角度来说，AI 擅长这个技术栈：
- 最新版 React
- 最新版 Tailwind
- Vite 用于高速构建
- Zustand 用于简化状态管理
- Shadcn/UI 用于美观的组件
- React Query 用于数据获取
- TypeScript 用于类型安全
- ESLint 用于代码质量
- Prettier 用于代码格式化
候选 Biome，eslint 和 prettier 二合一的存在。处理速度很快，而且有更多代码优化规则（例如 if 提早 return 了就不用 else 了，AI 写出来还是基本带 else 的）
React、Tailwind 几乎是标配市面上众多 App 生成网站（Lovable、Bolt等）默认输出都是用这个组合。
上面提到的 V0 图生组件，它生成的结果就是 react 组件，用 react 就能拿来即用。
以后开源库的用户量也是变得越来越“赢家通吃”。AI 越懂的库，用户越多，用户越多，训练材料越多，AI 越容易写好，然后循环了。
前后端融合
如果一个人同时管理前后端代码，那么强烈建议前后端仓库放到一起。又或者直接回到前后端不分离的时代，潮流果然是个圈。
实际效率提升
实际效率提升可能没有那么明显，一些对照实现显示效率提升可能在 20% 左右，甚至有的实验结果是负提升。
最后 30% 的耗时
70% 问题： 许多开发者发现AI能完成约70%的初始解决方案，但剩下的30%令人沮丧，可能导致“一步进两步退”的问题。非工程师尤为如此，他们缺乏理解代码的底层心智模型，难以修复 AI 引入的新 bug。
对于 70% 问题，现阶段对于完全 Vibe Coding（不理解代码）的使用者应该是无解的。但是作为程序员，我们必须在每次提交前初步理解代码，懂个大概即可，遇到错误再细看。我会更习惯直接用 git 检查 AI 更新的代码，而不是用 AI 工具自带的那个采纳或拒绝，直接全部采纳然后在 git 工具用 diff 检查会比较符合我原来的习惯。
对时间的错觉
开发者花费额外时间验证、调试和调整AI的输出。AI可能产生切线或不正确的代码，然后需要人工纠正。本质上，“幻觉”和错误步骤引入了额外的循环。
开发者可能过于容易接受 AI 输出，然后在错误时调试更长时间，而不是编写更简单的正确解决方案。研究指出，即使在经历减速后，开发者仍然感觉 AI 帮助了——一种认知偏见，因为 AI 让事情感觉更容易，即使它实际上并不更快。
更碎片的思维
尽管可以并行的任务更多，但这对人类本身大概不是好事。
这彻底打破原来有可能产生的心流，你不可能盯着 AI 编码，即使你不嫌盯着它浪费时间，你的眼睛也很难跟上它的实现。但你不盯着就意味着你打断了当前任务去干别的事了。
这会产生一个很恐怖的效果。现代人碎片化的注意力更稀碎了。
编码之外
- 无法缩短跨团队合作时间
- 无法缩短会议时间
该学什么
- 学会提问
- 精进调试策略
- 测试边界条件
- 熟悉性能优化原理
- 成为架构师，运维也参一脚
- 创意 UI/UX 设计（就我看来现在即使提示词鼓励它把界面做的有创意，结果还是逃不出很普通的页面结构）