【万字】Gemini 到底能不能杀死程序员？聊聊AI编程
叶小钗约 22 分钟关注公众号，回复666，获取AI全路径学习资料
上周，跟律师行业做了相对深度的AI交流：
<<< 左右滑动见更多 >>>
我也惊奇的发现一个情况，所谓传统五大中产医师/教师/律师/工程师/分析师这个群体，对AI的理解都还可以：他们愿意学，且学得有点样，具体表现为：
可以利用Coze搞点工作流AI的东西，稍微夸张一点的是开始使用AI编程，并取得一定成果...
这里需要特别提一点的就是AI编程，这批律师是真的没有代码基础的，这也从另一个角度说明了编程这件事的门槛在急剧下降，而从近期Gemini3.0发布，就一直在“渲染”的前端已死，也可以看出端倪。
所以，这里结论是：AI编程很重要，他对程序员行业影响很大，但你真要说AI消灭了程序员，那又是不对的，事实上AI Coding 的发展应该说是我们即将进入自然语言编程时代。
就我这两年的经历：真实在几个公司复杂AI项目的情况是：核心代码1万行左右，提示词大几十万行。
可以认为，提示词的编写就是自然语言编程，所以AI并不会消灭程序员，他消灭的是只会工具使用的那一部分，非要给个称呼我觉得可以叫代码搬运工。
只不过，各位程序员要尤其清晰的是：开发范式开始转移了，接下来需要和很多“非专业”（如产品经理、医生、律师）抢占提示词编写权限（工作量），你们做好准备了吗
综上，由于AI Coding 如此重要，所以我们今天来简单写一篇文章，以帮助各位快速了解：
实践是最好的老师
AI行业变化过快，以工具、技巧学习的方式接触AI Coding 很容易做无用功，所以我们真的想学，有两个点要注意：
想办法解决实际问题，以战练兵，带着目标学习的方式是非常快的； 打好基础，“以战养战”虽然效率很高，但同时会有下限很低的问题，所以在有基础认知后，还是需要系统性的学习，AI技术基础能力的重要性远超所有；
所以，想要零基础学AI编程，可能还是得走完AI Coding 爬坡的基础三阶段：
提示词工程； 理解工作流； 案例实践；
这里首先说说提示词工程：《提示词工程》
其次是工作流：《工作流AI方法论》
最后就是今天的重点案例实践了，这里我们先说方法论再实操！
AI Coding 方法论
这里案例实践假设你是一名毫无技术背景的产品经理，所以一些描述会“啰嗦”一点，懂行的同学略过即可。
实际开发流程包括：需求拆解、架构设计、提示工程、代码生成、多轮迭代、前后端搭建和部署测试等步骤。
AI Coding的核心思路是：让AI参与到每个开发阶段，充当智能助手或“结对编程者”，说白了你就是产品经理，他就是程序员（代码搬运工）。
具体实施下来，不同阶段会有不同的注意点：
一、需求拆解
对于程序员来说，写代码的前提是需求明确，与AI结对编程也是如此：AI再聪明，也需要清晰的指令才能发挥作用。
所以，动作的第一步是需要将业务梳理成清晰的功能（技术）模块，假设需求是开发一个简单的用户反馈收集工具，允许用户提交反馈，产品经理可以查看和导出反馈。这可以拆解为以下模块：
一个前端页面包含反馈表单； 后端提供提交反馈的API接口，将反馈保存到数据库； 一个管理后台页面（或至少导出功能）查看反馈列表； ...；
然后比较不好的做法是告诉AI：帮我做个收集反馈的工具...
当然，很可能你确实对互联网项目（流程）一无所知，这个时候也没关系，直接启用AI协助即可，常见的问法是：
要实现XX功能，需要哪些技术组件？ 我要开发一个用户反馈收集网页，应该选用什么前后端技术栈？
模型自己就会给出很多信息，包括技术选型...
在这一阶段提问AI时，要尽可能提供上下文和限制条件。如明确用户规模数据类型等。比如下属提示词：
我需要一个Web应用来收集用户反馈。
每天约有100条反馈，需存储文本和用户联系方式。
我希望有一个简单后台查看所有反馈。
请问我应该选择怎样的前端、后端框架和数据库？需要哪些主要模块？
提示词需要明确需求细节和非功能需求（规模），AI将据此给出更定制化的方案。
二、架构设计
明确需求后，下一步是架构设计。这意味着确定整个应用需要哪些页面/界面、后台服务、数据存储，以及它们之间如何交互。上述工作在AI辅助下，已经工作流较小了：
一、拆解前后端任务
我们需要一个前端页面让用户填写反馈；
一个后端接口接收提交；
可能还有一个前端页面供管理员查看反馈或一个接口导出数据。
将每个模块的职责简要描述出来，然后可以请AI检查是否全面。
过程中，AI或许会提醒你比如需要表单验证模块、错误提示等细节。这种与AI讨论架构的过程，好比和经验丰富的工程师讨论方案。
二、生成项目结构
任务拆解结束后，Cursor会生成简单代码组织结构，比如：
前端：index.html, feedback.js...；
后端：app.py 或 server.js...；
数据库：schema.sql 或使用SQLite文件...
这些输出可以作为进一步实施的指引。需要注意的是，AI建议的项目结构是通用的，他应结合实际调整（比如是否需要将前后端完全分离）。但总的来说，在规划阶段AI就能给出相当可行的骨架。
对于有一定技术背景的PM，也可以让AI给出更详细的架构设计，例如数据库实体关系建议、API接口设计等：
请设计反馈接口的API，包括请求方法、URL、请求参数和返回格式
# 这样的提示会让AI产出类似Swagger风格的描述。例如：
POST /api/feedback - Body: {user, contact, message}
Response: 201 Created or error code
这些细节设计输出可以大大加快后续实现环节，并减少来回修改。
三、提示词编写
到这里，之前我们学到的提示词技巧（《提示词工程》）就该派上用场了：
用清晰的语言“告诉”AI你想要什么功能和行为，是整个AI编程过程中最核心的一环。为了更直观，我们来看一个简化版的提示及AI生成代码结构：
**用户提示：**
请使用Python Flask创建一个简单的待办事项(Task)管理API，包括：
- 列出任务的接口 (GET `/tasks`)
- 新增任务的接口 (POST `/tasks`)
- 删除任务的接口 (DELETE `/tasks/<id>`)
每个任务包含 `id`, `title`, `done` 三个字段。请给出完整的Flask后端代码。
当我们给予这样的明确提示，AI将产出相应代码。生成的后端代码可能如下：
from flask import Flask, request, jsonify
app = Flask(__name__)
tasks = [] # 用于存储任务的简易内存数据库
@app.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify(tasks)
@app.route('/tasks', methods=['POST'])
def create_task():
data = request.get_json()
task = {
"id": len(tasks) + 1,
"title": data.get("title", ""),
"done": False
}
tasks.append(task)
return jsonify(task), 201
@app.route('/tasks/<int:task_id>', methods=['DELETE'])
def delete_task(task_id):
global tasks
tasks = [t for t in tasks if t["id"] != task_id]
return'', 204
if __name__ == '__main__':
app.run()
PS：以上代码为AI根据提示生成的示例，省略了错误处理和完整性检查。
清晰的让AI明确要实现哪些接口，以及数据结构，从而直接生成了可工作的代码雏形。接下来就是进一步要求AI为前端提供HTML/JS代码，与此后端进行交互，实现Todo任务列表的展示和管理。
四、迭代开发
在实际工作中，单轮替换就想成功是比较少见的。通常需要不断追问、澄清、追加要求。例如，如果AI生成的后端代码缺少某些错误处理，需要继续提示：
请在新增任务接口中添加当请求body缺少title时的错误处理，并返回400错误。
AI会据此修改代码。如果前端页面样式很简陋，我们可以要求：
请使用Bootstrap美化页面。
这种多轮迭代是Prompt工程的一部分：通过逐步细化和纠正，让AI输出逐渐符合预期的结果。
在迭代过程中，不要一次性提出过多修改意见，最好一条条分开提出，让AI逐一处理。这样避免模型遗漏某些要求，并便于观察每次修改的效果。
迭代是常态。你需要扮演“产品经理”和“测试”的角色，在每轮AI输出后进行验证，再决定下一步的修改或优化方向。以下是一个完整流程：
一、生成初版代码：
让AI先产出第一个版本的代码（前后端模块皆可）。得到代码后，尝试运行（如果有条件，可以将后端代码运行起来，或者用在线工具运行，前端代码则直接用浏览器打开），观察是否实现了基本功能；
二、分析问题与反馈AI：
初版代码大概率会存在一些问题或者不足之处。比如，某个功能没有按照预期工作、存在bug，或者有改进空间，如缺少输入验证、安全保护、UI不够美观等。
记录下具体的问题。例如：“删除任务功能没有生效”或“提交反馈表单时缺少成功提示”。
然后在对话中把这些具体的问题反馈给AI。由于AI拥有前面的上下文，它能够理解代码含义并定位问题
......
这一过程其实就像调试对话：AI既扮演了解释器也扮演修复者。
三、引导AI修复：
针对发现的问题，要求AI修改代码。继续上例，可以说：
请修复删除任务后任务列表未更新的Bug。
AI可能定位到具体问题，然后给出修正版代码，此时仔细检查AI的改动，有助于学习AI是如何定位并解决问题的。
很多非技术PM通过这种方式，逐步掌握了简单的调试技能，因为AI会解释“问题在于X，因此我将代码Y修改为Z”。
除了修Bug，还可以让AI逐步完善功能，比如在初版基础上：
请增加任务完成标记的功能 (done 字段置为True)
每提出一个新需求，AI都会在现有代码上做增量修改。
四、反复测试：
每次AI给出新的代码，都应该再次运行或检查。
对于Web应用，可在浏览器中多操作几次各功能，模拟用户行为，观察是否还有遗漏。
例如，提交空内容时会怎样？并发提交有没有问题？这些测试发现的新问题，再交给AI处理。
经过几轮迭代后，应该能得到一个基本满足需求的版本。此时如果时间允许，最好进行一次代码走查，产品这东西只要你想优化，就一定有可以优化的地方。
插曲：调试技巧分享
这里有几点实践经验供参考：
保持每次修改的单一性：如前所述，一次只让AI修改或增加一处功能。这样更易定位新问题。如果一下子提出十项修改，AI可能顾此失彼，或生成的大段代码不便于逐项验证； 勇于推翻重来：有时经过多轮修补，代码可能变得混乱。AI毕竟不是老工程师，可能引入冗余或绕路实现。如果感觉代码质量下降，干脆从头再生成一次。AI推倒重来几乎零成本。因为你对需求描述得更好了，很多时候第二遍生成的代码会比第一次思路更清晰； 保存每个阶段的代码：养成立即保存AI输出代码的习惯，以便回退或比较版本差异； ...
五、集成
前后端代码都完成后开始做集成。
如果之前分别让AI生成了后端API和前端页面，需要确保接口路径、数据格式一致。
例如后端约定了/api/feedback的POST接口，前端提交时的URL和JSON字段名必须匹配。
AI在不同对话中生成，容易出现不一致，最好在同一个上下文里让AI了解前后端需要配合。可以先生成后端，再对同一个AI说
下面生成前端代码，请调用刚才定义的API接口。
如果前后端是在不同模型或不同工具中生成的，整合时发现不对应，也可以将后端规范提供给前端生成的AI，让它修改代码以对齐。例如：
后端要求POST请求JSON里字段名为message，请修改前端fetch代码按此格式发送。
前后端集成常见问题依旧是跨域问题，对于很多非技术PM来说，调试这些问题有一定难度，因为很容易不明就里。
如果出现CORS错误，可以把错误信息贴给AI，它会告诉你需要在后端添加CORS支持并给出代码（如使用Flask-CORS库或在Express设置响应头）。如果数据格式不符，也可以把前端发送的数据示例和后端期望格式告诉AI，请它找出差异。
最后，集成之后，前端的用户体验往往需要打磨，这里再次进入返回迭代即可...
六、部署
在本地运行良好后，就进入部署测试阶段。
对于原型项目，部署环境可以很简单：例如将前端托管在静态网页服务（如GitHub Pages、Netlify），后端部署到云服务（如Railway、Heroku的免费方案）。
这里其实最难的应该是部署流程的不熟悉，这也可以完全让AI指导完成：
一、环境搭建：
询问AI需要怎样的运行环境。例如：
如何将Flask应用部署到云服务器？
AI会给出安装Python、设置虚拟环境、安装依赖、启动应用的方法。
二、云服务：
这里也不要慌，云服务就看上去难罢了，现在很多云平台提供一键部署，只是需要编写配置。
在内部部署好原型后，可以邀请小范围用户试用。收集到的新需求或问题，再反馈给AI继续改进迭代...
上述是AI Coding 偏方法论的部分，接下来是那个案例的具体实操：
案例实操
考虑更适应于国内多数同学，这里使用的AI编程工具是TRAE，网站：
https://www.trae.ai/
可以使用海外版本的TRAE，国内限制了一些基座大模型的调用。具体工作过程中可以同步使用ChatGPT协助，他可以给到很多初始信息：
暂时来说，ChatGPT在这块能力挺强的（主要我一直是付费用户）：
一、代码之前
先操作后端项目，让ChatGPT给我们单独的后端项目结构，把拿到的文本内容一键复制到TRAE中，ChatGPT给我们梳理好了项目结构就出来了：
feedback_app/
│
├── app.py # Flask 入口
├── config.py # 配置文件
├── extensions.py # 数据库、JWT、CORS 等扩展初始化
│
├── models/
│ └── feedback.py # Feedback 模型
│
├── routes/
│ ├── feedback_api.py # 用户反馈接口
│ └── admin_api.py # 后台管理接口
│
├── services/
│ ├── feedback_service.py # 反馈业务逻辑
│ └── admin_service.py # 管理员业务逻辑
│
├── utils/
│ ├── auth.py # JWT / Token 工具
│ ├── validators.py # 参数校验
│ └── pagination.py # 分页工具
│
└── requirements.txt
把拿到的文本内容复制粘贴到TRAE中：
在TRAE中选择你的基座大模型，通常我们使用Claude的模型，但是前段时间，Claude被下架了，代码能力稍微好一些的是GPT-5或者Gemini模型，但是如果你是下载的国内版本的TRAE的话，可能搜索不到这两个模型。
因为基本的项目结构我们已经放到了TRAE中，现在只需要简单的提示词编写即可，可以直接选择这个文件放到对话框中，TRAE编辑器就会自动取识别这个文件里面的信息，读取刚刚填写的这个项目结构。
这里要说明一下，把文件放置对话框，最好是单个文件，或者几个文件给到对话框，也可以区域选择代码给到对话框，一般不要把整个文件夹给到对话框，不然token消耗极快，编辑器反应也非常慢。
在正式写入代码之前，我们总结一下：
接下来进入代码环节：
二、后端
现在把项目结构交给了TRAE，但是如果我们不知道怎么给AI编辑器定义要求，跟上面ChatGPT分析需求一样的路径，命名ChatGPT给我们一段AI编辑器的要求：
怎么编写要求，让AI编辑器更好的跟着项目来编写项目
虽然ChatGPT给的Cursor编辑器，但无所谓，AI编辑器都是通用的：
在编写代码之前要把项目内置的智能体选择Builder模型，这样编辑器才有权限写入文件到你的电脑中：
现在就可以等待几分钟，AI编辑器-TRAE会调用ChatGPT模型，分析项目进行代码编写：
TRAE在编写中会主动请求运行命令行，只需要点击运行即可，你也可以把命令行加入到白名单中，TRAE就不会发起请求直接运行命令行。
这里给个建议，不要添加任何命令行到白名单中。有时候TRAE会抽风，删掉或者修改部分文件，在项目代码较多，依赖关系复杂的情况下，TRAE删掉的部分反而会增加审查工作量。
TRAE运行完成后，我们就可以看见左侧资源管理器中就多了很多文件：
编写完成后，先启动看看是否报错：
我们可以看见下面图片中，项目运行在这个地址
Running on http://127.0.0.1:5000
这就说明项目启动成功了，警告信息可以不用管，这是在提醒我们这是在开发环境，如果要线上使用的话更改服务器：
现在代码是正常启动状态，但是不知道接口是否可以正常请求，可以用postman，apifox等工具进行接口测试，直接生成前端页面进行前后端联调，这样更直观。
找到controller层，可以看见有/login 这样的路径，把这个文件给到对话框，让AI帮我们整理接口文档：
让编辑器帮我们整理接口文档，写到对应的文件里面。
这里说明一下：代码文件的命名一般使用英文格式，多个单词使用"_"下划符号链接，我这里是markdown格式的文档，为了方便观看使用中文名字：
后端结束后就是前端代码了：
三、前端
现在我们重新打开一个TRAE窗口，用于编写前端代码：
然后再去ChatGPT生成对应了前端代码结果提示词，把刚才后端生成的接口文档复制到项目中。
这里跟上面一样，把项目结构放到对话框，让编辑器生成对应的前端代码框架，这里我没有提供另外的要求，当然你也可以限制要求，安装对应的依赖：
框架搭建好以后，TRAE会自动请求运行项目，项目运行后发现正常运行，那么我们的前端现在也搭建好了，现在有点丑也没关系，先查看是否可以正常链接到后端：
把后端生成的接口文档交给编辑器，编辑器会阅读接口文档，根据文档对接后端的接口：
选择提交后显示提交成功，那么说明与后端的链接的贯通的：
如何查看我们刚刚填写的数据呢？
1.配置本地SQL服务，比如localhost这个MySQL的本地服务
2.前面我们提示词是直接使用SQL保存到了文件当中，需要提前安装SQL插件才可以正常访问这个.db文件
数据正常返回，说明，前端请求到后端，后端保存到数据库，这个基本业务逻辑是通的，剩下就是优化代码：
四、调试迭代
在优化之前先要梳理需要优化的问题，比如：
页面太丑； 我们有登录的逻辑，但是页面启动没有登录页面，直接就是反馈填写；
先解决登录问题：
登录问题解决后，现在解决美化问题，当然美化的提示词也可以使用ChatGPT生成：
你现在是一个资深前端架构师 + UI/UX 设计师，我正在开发一个 Vue 项目（Vue3 + Vite 或 Vue2，请自动识别现有代码）。
请基于我当前的 Vue 项目结构，对页面进行全面的 UI 美化与渲染优化，要求如下：
# 🎨 设计风格要求
- 风格现代、简洁、响应式
- 使用流畅的过渡动画（如淡入、滑动）
- 色彩清爽，有统一主题（如浅色主题 + 主色调）
- 布局精致：合理的间距、卡片式布局、阴影、圆角
- 支持移动端友好展示
# 🧩 技术要求
- 保留我的业务逻辑，不影响功能
- 可以引入 UI 框架（如 Element Plus / Ant Design Vue / Vuetify / TailwindCSS），根据代码习惯自动选择最匹配的方案
- 样式统一使用：CSS / SCSS / Tailwind（根据我项目自动判断）
- 添加合理的组件拆分、复用结构
- 提供优化后的 `<template>`、`<script>`、`<style>` 完整代码
# ✨ 页面效果要求
请为页面加入以下美化处理：
- 统一的整体布局（容器 + 页头 + 页面内容）
- 卡片布局（圆角、柔和阴影）
- 按钮与输入框采用现代 UI 风格
- 加入加载动画/空状态界面（loading、empty state）
- 添加 Hover/激活态效果提高交互性
- 如界面中存在表格/列表，请改成更美观的展示样式
# 📦 输出要求
请输出：
1. 优化后的完整组件代码（template/script/style）
2. 若使用 UI 框架，请给出安装命令
3. 如需全局样式（如主题颜色），请给我对应的代码
4. 如需公共布局组件，请自动帮我创建
请直接在理解我现有代码后给出最优方案。
把生成好的提示词写到项目文件中，现在利用的基座大模型是Gimini-2.5-pro, Gimini-2.5-pro在美化前端页面代码，要比其他基座大模型效果更好，所以切换为Gimini-2.5-pro，当然你也可以使用现在很火的Gimini-3-pro，只不过TRAE现在没有提供，后面应该会上架：
优化完成后，编辑器会请求启动项目，这个时候项目启动报错，因为是编辑器启动的项目，所以在识别到报错信息后，它会自动识别错误并且改正：
再次启动项目后发现的确美观了很多，但是直接请求了反馈填写，而不是登录，所以还要继续调整：
经过几次修改后页面就可以正常返回数据了：
现在开始添加新功能，待办事项
新功能添加成功以后，调试的方法还是和前面一样，前后端联调，根据报错信息一步步调整，最后一步就是给项目添加日志：
至此，基本流程差不多了：
五、建议
事实上，我们用的比较多的是Cursor因为他效果会更好一点，Claude Code这个没办法，但后面点同质化会很严重的。优化后页面展示：
然后，提交代码到远程仓库：
✔ Step 1：进入你的项目目录
cd 你的项目路径
如果没有项目目录，先创建再进入：
mkdir my-project
cd my-project
✔ Step 2：初始化 Git 仓库
git init
创建一个 .git 文件夹作为版本库。
✔ Step 3：检查当前文件状态
git status
✔ Step 4：添加所有文件到暂存区
git add .
✔ Step 5：提交为一次 commit
git commit -m "Initial commit"
✔ Step 6：在 GitHub 创建一个远程仓库
例如创建：
https://github.com/<你的用户名>/<仓库名>.git
复制这个地址备用。
✔ Step 7：设置远程地址 origin
git remote add origin https://github.com/你的用户名/仓库名.git
✔ Step 8：确认远程地址是否设置成功
git remote -v
当然也可以只用可视化工具进行提交，使用jetbrains的编辑器进行代码提交这里不做扩展...
五、后端部署
利用三方平台进行部署，三方平台部署需要对部分代码文件进行更改，可以直接在编辑器中让AI帮你修改项目中需要更改的配置文件：
因为是教程部署顺序无所谓，先部署后端再部署前端，后端经过几次调试后部署到railway上：
这个健康审查要求也是编辑器在识别报错信息后添加的。
在对railway不了解的时候，建议把railway地址给到编辑器，让AI去读取railway的对接文档，识别报错信息后，根据对接文档，进一步修改对接代码，达到部署的要求：
六、前端部署
前端使用Netlify进行部署
把报错信息交给ChatGPT进行分析，最好是把网站地址也给到ChatGPT，结合实际情况修改对应的步骤。
部署项目当中出现的问题，除了给AI分析，还可以查看开发文档，也能解决问题，等待部署成功后：
至此，这个demo就被推到线上了，整体流程：
这里我们简单实操也就结束了，看着这个教程，逻辑上小白用户也能处理，接下来我们说说工具选择问题：
AI编程工具选择
现在各个基模几乎都在卷编程模块，除了占据程序员工作台入口以外，编程这件事本身就很接近“造物主”，基座能力这块能力强了，无论是后续的Agent工具调用还是自我进化速度都与其相关，所以当前AI编程工具这块也是卷得飞起！
从微软的GitHub Copilot到字节跳动的Trae，从OpenAI的ChatGPT到腾讯的CodeBuddy，选择哪款工具也是各个CTO很关心的问题。
我们这里做案例使用的是Trae，这是因为考虑各位入手门槛，事实上真正好用的还是Cursor、Claude Code 等国外工具，只不过国内跟进的很快啦。
想要评价一个AI编程工具是否好用，可以从可用性、代码生成质量、稳定性、语言支持、集成能力、安全与隐私、适用场景、用户类型适配性等维度出发，但其实也不用力，因为同质化真的比较严重。
可用性
衡量一款AI编程工具的可用性，需考虑其上手门槛，用户体验这件事怎么强调都不过分。
大部分代码补全类工具以插件形式集成到主流IDE，上手难度较低。例如GitHub Copilot可以无缝接入VS Code、JetBrains等常用编辑器，Amazon CodeWhisperer则融入AWS开发套件中，对于已有这些生态经验的开发者来说几乎零学习成本。
腾讯的CodeBuddy同样提供插件，支持IntelliJ IDEA、VS Code等IDE以及CLI模式，安装配置简便就是使用便捷。
相比之下，Cursor属于基于VS Code改造的独立编辑器，需要下载单独的客户端；但由于界面与操作习惯接近VS Code，VS Code用户上手也比较快；
Replit则是在线IDE平台，新用户需适应其云端开发界面，好在其学习曲线相对平缓，界面简洁直观，很多学生和初学者都能很快上手。
另一方面，很多非专业开发者，也喜欢使用Cursor这类IDE，因为可以帮他们做文件读取，他们有些将其当成了智能体来使用，而事实上这是Coding IDE 演变为Agent的模式会非常顺滑！
代码质量
解决门槛问题后，首要关注点就是生成质量，包括代码正确性、智能程度、上下文理解能力等。不同产品背后的模型能力不同，导致代码输出质量有高有低：
现阶段公认较强的编程模型是OpenAI和Claude系列，近期Google的Gemini表现也非常强势，其中：
ChatGPT的代码理解和生成能力极强，复杂算法和边缘案例上往往给出接近最佳的解答。Claude 上下文窗口大，可以一次性分析长达上百页的代码，对超长文本/代码的处理独具优势。而Gemini3.0近来的广告是杀死前端，具体下来，都能使用各有侧重，但最终同质化会很严重。
很多编程工具都是围绕上述模型做功能，他们的逻辑很清晰：你的能力是60分，我只需要做到70分就行，其中的代表就是Cursor，现在有些智能体如Manus也有点这个思路。
其次，场景化（本地化）体验比较关键。比如Trae针对中文编程场景做了优化，对中文注释、变量名等模块做了处理。
具体下来Trae对中文需求的支持大概率是超过Cursor和Claude Code的。
总而言之，代码质量属于是否问题，只要这块表现不行，那就不会被选择。
稳定性
稳定性包含两个层面：一是工具本身性能和服务的稳定可靠，二是所生成代码的一致性和可控性。
以Claude Code为例，他这种具有针对性的工具，国内几乎是很难选择的。
整个这个方面，可以描述得不多，直接无脑选大厂就好，这样不会怕他突然关门！
集成能力
集成能力指AI工具与开发者现有工作流、开发环境以及其它工具链的结合程度。这块有点类似之前门槛部分；
总的来说，Copilot一类插件式工具集成较为广泛，几乎“即插即用”，Cursor/Trae一类IDE型工具内聚能力强但局限于自身环境，而像CodeBuddy这样支持多端的工具则在灵活性上独树一帜。
企业选型时应盘点团队现有开发环境和工具链。
......
最后给一个表格吧：
AI编程的局限性
尽管AI编程展现出惊人的威力，但目前仍有明显局限和边界需要我们理性看待。比如在芯片编程领域上，现有的AI模型并不擅长甚至无法胜任。
所以，理解AI编程有什么短板，以及为什么会存在这些不足，对于深度AI编程的理解有重要的意义
首先是AI不擅长的小众领域。当前AI对芯片编程、硬件编程、并行计算底层优化等领域仍显无力。
其他我不大了解，但芯片领域我身边刚好有几个朋友，他们在成都的现状是：年薪给到百万，但依旧找不到合适的人，因为搞这个的人太少了！
现在最大的问题是什么呢？因为训练数据极少，大模型对它们掌握有限，甚至由于公开代码匮乏，模型很可能连基本语法都不了解。
并且因为模型没有针对性微调训练，即使提供样例，模型也容易出错或遗忘规则，比如要求AI写一个Zig语言，模型可能答不上...
这在企业内部自定义代码库上也类似：如果你的公司有一套自研DSL，拿开源模型来写肯定一问三不知。
那么怎么办呢？只能进行专门微调，这也提醒我们：AI能帮忙的范围与训练数据范围密切相关，超出那个范围就变成“无米之炊”，很难期望模型发挥正常水平。
这里还遗留了一个问题，为什么不去训练呢？答案是ROI过低！
模型的训练任务依旧遵循28原则，他们现在解决20%常用的增删查改网页设计（包括小程序设计），已经可以解决市场上80%的问题了，所以基模也没那个兴趣花大力气解决长尾问题
而且当前模型是有本质缺陷的，换句话说当前模型虽然看上去很聪明，其实依旧在概率堆积，而且哪怕引入CoT思维链，效果也有限，其生成模式导致一旦走错一步，就会错误连锁，很难自行完全纠正。
所以，当前AI编程表现出来的强力效果，尤其在前端领域的强力体验，其实是基模花大力气训练出来的，如果这个都做不到，那也就白瞎了那么多资源投入了...
关于，如何解决小领域AI编程问题，这块我们也正在实践，完整结果还没拿到，只能说这个方向是可行的，但困难很多，后面有结果再跟大家做汇报吧。
除了微调外，也有人用提示词的方式在做产品训练，这里不能说完全没效果，但意义不大，因为模型可能连基本语法都没学会，而且当前模型的上下文是不存在你把一本书传进去的...
结语
小众领域AI编程能力的提升，是一个工程技术+领域KnowHow的经典组合。
通过微调、提示等技术手段教会AI专业知识，另一方面要有领域专家的输入和验证闭环，让AI不断迭代变得更可靠。
而如何借助AI获得工程技术（或者工具使用能力），再运用我们领域KnowHow解决实际场景问题，就是AI编程真正的核心了。
AI编程并不难，很多人都能学废，AI编程也不是一定会淘汰谁，只不过懂业务这个点被提到了更为重要的位置了。
好了，希望文章对各位有用！
点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：