1. 内容整体设计与思路拆解1.1 为什么个人开发者必须重新理解AI编程过去一年我自己写代码的方式发生了很明显的变化。以前接到一个需求第一反应是打开编辑器从空文件开始一点点敲现在第一反应是打开AI编程工具先描述清楚我要什么、边界在哪里、有哪些约束让工具先出一版骨架我再review、改细节、补测试。这个过程看上去只是把“写代码”变成了“改代码”但底层的思维模式是完全不一样的。这种变化对个人开发者尤其重要。团队里有架构师、有严格的Code Review流程、有专门的测试环境AI犯的错还有人多层把关但个人项目往往一个人说了算没有人帮你盯着。这时候如果盲目信任AI生成的代码坑会埋得特别深。所以个人用AI编程核心不是“会不会用某个工具”而是“怎么建立一套适合自己的、可控的、可复现的工作流”。我在实践里总结的经验是AI编程本质上是一种“结对编程”AI是那个手速极快但经常犯迷糊的结对伙伴你是那个负责定方向、划边界、做决策的司机。搞清楚这个角色分工后面所有工具选型和方法论都有了解释。1.2 这篇文章适合谁读、能解决什么问题这篇文章的目标读者很明确已经在写代码、但还没系统用过AI编程工具的个人开发者以及那些用了AI但总觉得生成质量不稳定、不知道问题出在哪的人。如果你是完全零基础连Git是什么都不知道这篇文章对你会稍微有些吃力但你仍然可以先把工具选型部分看完选一个图形化界面好用的工具跟着实战部分的思路跑通一个极小的demo之后再慢慢补基础。如果你已经用AI写了不少代码但经常遇到“AI改一处坏三处”“生成的代码一堆bug”“上下文一长就失忆”这些问题那重点看第3章和第4章。这里有我实际踩过的坑和一些具体解法不是那种“你真棒继续加油”的空话。文章的最终目标不是让你成为“提示词工程师”而是帮你建立一套“人机协同”的工作习惯AI负责产出草稿、查文档、写测试你负责设计、审查、决断。2. 工具选型个人可用的AI编程工具全景与选择逻辑2.1 主流工具实测对比市面上的AI编程工具已经很多了我按“使用方式”和“适用人群”大致分了几类先把实际用过的放一张表里后面再逐个说感受工具类型最适合的场景上手成本注意事项GitHub Copilot编辑器插件日常补全、写样板代码低对项目上下文理解有限需要你自己把话说清楚Cursor独立IDE边聊边改、跨文件重构中基于VSCode迁移成本低AI会改到你不想让它改的文件Cline原Claude Dev编辑器插件让AI自己读文件、跑命令、改多文件中高需要API Key费用要心里有数动作比人激进Codex CLI命令行工具在终端里让AI干活、配脚本中对命令行熟的人效率高新手容易懵ChatGPT/Claude 网页版对话界面需求分析、代码理解、写零散脚本低无法直接读本地项目需要复制粘贴且上下文有限Trae、通义灵码等编辑器插件/独立IDE国内网络环境友好、中文支持好低可选效果好但取决于具体版本OH MY PI 类本地智能体自部署智能体隐私要求高、想折腾高配置复杂对个人项目来说维护成本很高2.2 按使用场景选择而不是按排行榜选择很多新手会纠结“到底哪个AI编程工具最强”但我的建议是反过来先想清楚你最常写的代码是什么类型再选工具。如果你是写前端页面、天天调CSS、写React组件那么GitHub Copilot在编辑器里的行级补全体验非常好因为它能根据你正在写的代码实时推测下一行你不需要专门去“对话”它就在那里。这种“无感辅助”对日常敲代码的效率提升是最直接的。如果你经常接到一个需求“帮我看看这个模块为什么跑不起来”或者“把这段老代码重构一下”那适合用Cursor或者Cline这类可以跨文件读取上下文的工具。因为单靠行级补全解决不了这类问题你必须让AI看到整个项目的结构、相关函数、配置文件才能给出有意义的答案。如果你只是想临时写个脚本处理Excel、写个爬虫抓数据那根本不需要在IDE里装什么插件直接用ChatGPT或者Claude的网页版把需求描述一遍拿到代码再在本地跑效率是最高的。我自己现在的工作方式是打开VSCode日常补全交给Copilot类似能力的插件遇到需要理解项目整体逻辑的活切到Cline让它读文件、改代码需要快速验证想法的时候浏览器开一个对话窗口。三个工具各有各的用途不存在“一个工具打天下”的情况。2.3 工具选型的三个判断标准判断一个工具适不适合你我建议从三个维度去评估。第一个是上下文窗口。这里的窗口不是指它能记住多少轮对话而是它能不能真正读取你本地项目的文件。我试过用网页版工具改一个大型项目里某个函数结果只能把相关代码复制粘贴进去一旦文件之间互相引用对话内容很快就超出窗口限制AI开始胡说八道。所以接大项目优先选能直接读文件、自动把相关代码带进上下文的工具。第二个是释放权限的边界。越强大的AI编程工具越会主动替你执行命令比如装依赖、跑测试甚至改文件。这确实方便但也意味着风险它可能在你没注意的时候多删了一行、多装了一个乱七八糟的包。个人项目不像公司项目有沙箱或者专人看护建议只在你有信心回滚的场景里放开权限。第三个是费用结构。很多工具都是订阅费加API调用费的模式看似不贵但如果你天天让它读文件、跑长任务一个月下来账单可能很吓人。个人开发者建议先按量预估一下或者设置一个月度预算别等账单出来才傻眼。3. 提示词与上下文管理AI编程的隐形技能3.1 不要把AI当搜索引擎要把它当新同事很多人觉得写提示词就是“把需求说得更详细一点”这个理解没错但不全面。我更喜欢用一个类比AI是一个刚入职、干劲十足但完全不了解你项目的新同事。你如果只说“帮我把用户登录功能修一下”它只能根据它在训练数据里见过的“登录功能”乱猜结果大概率不符合你的预期。正确的做法是在提问前把新同事需要知道的信息都给它这个项目的技术栈是什么语言、框架、包管理器代码在哪个目录、相关文件叫什么名字你要它做的事是什么最终交付物是什么有哪些约束条件比如不能改某个文件、必须兼容旧版本你希望它怎么输出直接改代码给一个解释写一个测试这些信息不一定全部都有但给得越充分AI的生成质量越高。我自己实测下来的感受是同样是让AI写一个“批量重命名文件”的脚本一上来只给一句话需求它会给一个常见的os.rename实现而如果告诉它“我需要处理1万多个文件路径中包含中文和空格最好支持预览模式我不想执行完才发现有问题”它就会自动考虑到编码问题、路径引号问题和干跑模式。这就是提示词带来的真实差异。3.2 一个可复用的提示词模板我平时写提示词会习惯性地按下面的模板组织。不是每次都要写得这么全但遇到稍微复杂的任务这个模板能帮AI少犯很多低级错误。角色你是一个熟悉{技术栈}的资深工程师。 背景项目位于{目录结构说明}使用{框架/依赖管理方式}。 任务目标{具体要完成的功能或要修复的问题含用户可见行为} 输入/输出示例{如果可能给一两组输入输出让AI准确理解格式} 约束条件 - 不要修改{某些文件或模块} - 保持与现有代码风格一致 - 需要考虑{边界情况如空值、并发、性能} - 不要新增不必要的依赖。 验证方式请给出你如何自测这个功能的步骤或者写一个最小测试用例。这个模板的价值不只是“给AI更多信息”更重要是让AI知道“你的判断标准是什么”。我见过太多人抱怨AI生成的代码不好但其实是从头到尾没告诉过AI“什么叫好”。你给它标准它就按标准干活你懒得给它就按它训练数据里的平均标准干活而这个平均标准往往撑不起一个正经项目。3.3 上下文窗口不够用怎么办AI工具都有上下文窗口超过一定长度之后它会“忘记”前面的内容。个人项目里最典型的问题是一个文件1000行AI只能记住一部分或者你让它改完A文件再让它改B文件时它已经把A文件里的逻辑忘干净了。我试过好几种办法比较实用的有三个第一个是拆分任务。不要试图让AI一次完成一个横跨多个模块的大功能而是把它拆成“首先实现一个工具函数然后写单元测试再接入现有调用点”这种粒度更小的步骤。每完成一步你检查一步、提交一步这样AI的上下文压力小你的审查压力也小。第二个是利用工具的文件引用能力。Cursor、Cline这类插件支持你在对话里直接某个文件或者自动把当前打开文件作为上下文。如果项目特别大你可以先把最关键的入口文件引用进来再让AI顺着入口文件去读它实际依赖的部分。不要一股脑把所有文件都拖进去上下文窗口会被无关代码塞满真正重要的信息反而被挤掉了。第三个是让AI先总结再动手。在让AI改代码之前先让它读一遍相关文件并用几句话复述它对这个文件的理解。这看起来多了一步但能非常有效地避免AI在错误的理解上动手。如果它复述得和你的理解不一致你还能及时纠正而不是等它改完20个文件之后才发现方向错了。4. 实操过程与核心环节实现4.1 从一个需求到一条通过的流程下面我以“给一个Python CLI工具增加--dry-run参数让它可以在正式执行前打印将要执行的操作”为例完整走一遍我平时与AI协作的流程。这个需求不复杂但覆盖了最常见的人机协作环节。第一步我会先用文字向AI描述需求套用前面的模板。给我的AI工具的信息大致是项目是一个Python命令行工具代码在src/目录下入口在src/main.py。 任务新增一个--dry-run标志当用户传入该参数时程序不真正删除文件而是在终端打印“将删除文件: xxx” 约束保持argparse的现有风格不影响其它参数要处理路径中的中文和空格。第二步我会让AI先给出这个功能的实现方案。注意这里不是让它直接改文件而是先在对话框里说清楚它打算怎么做、改动涉及哪些文件。如果它说“我会修改src/main.py新增一个if判断”那基本符合预期如果它说“我会在utils.py里新增模块”我就要确认这个模块是否真的有必要。第三步确认方案后再让它动手改代码。改完后我会让它列出它具体改动了哪些文件的哪些行。这是我自己坚持的一个习惯AI编程最大的风险不是它写不出代码而是它在你看不到的地方改了一堆你不想要的东西。第四步本地跑验证。CLI工具很好验证直接跑python main.py --dry-run看看输出是不是符合预期。如果AI生成的代码有问题不要急着让AI修先看报错信息再把报错原样贴回对话里让它解释原因并给出修改方案。4.2 用git worktree开一条AI专用的实验分支做AI编程时我强烈建议不要直接在主线分支上让它改来改去。AI的修改方向不一定是你想要的试错过程可能很频繁。如果在同一个工作区反复来回折腾不仅历史记录难看有些工具还会因为文件变动太多而大概率失忆。我的做法是用git worktree开一条专门给AI折腾的分支。这个功能可能很多人还不太熟但特别适合个人开发者尝试AI编程时使用。简单解释一下git worktree允许你从同一个仓库里检出多个工作目录每个目录对应不同的分支。这样你可以在原来项目目录不动的情况下在另一个目录拉出一个“AI实验区”让AI在那个目录里随便改。改坏了直接删掉那个目录重建主项目完全不受影响。实际操作大概是这样# 在项目根目录下 git worktree add ../myproject-ai-experiment -b ai-experiment # 这会创建一个新目录 ../myproject-ai-experiment # 指向新分支 ai-experiment内容和你当前分支一样。 # AI在那个目录里改完、测试觉得没问题再回到原目录合并 git worktree remove ../myproject-ai-experiment --force git branch -D ai-experiment这种做法的好处是AI产生的混乱实验不会污染你日常开发的主目录你随时可以在两个目录之间切换对比。坏处是如果你本身不熟悉Git一开始可能觉得麻烦。但我的建议是哪怕多花半天熟悉一下git worktree也值回票价。对经常用AI改代码的人来说这可以算最便宜的安全网。4.3 合入前的代码审查AI写的代码必须过三关AI写完代码不代表工作完成你自己的审查环节才是决定质量的关键。我给自己定了一个规则AI写的代码要过三关才能合入主干。第一关是逻辑正确性。它写的这个功能在正常输入下是否符合预期有没有明显漏掉的边界情况这一关相对容易只要你自己能把握整体需求就能判断个大概。第二关是风格一致性。AI生成的代码往往风格统一但未必和你的项目一致。比如你的项目用单引号它给你生成双引号你的项目函数命名用snake_case它用了驼峰。这些问题不会让程序跑崩但会让后续维护特别难受。我一般会让AI先读一下项目里某个代表性文件再让它模仿这个文件的风格写新代码。第三关是依赖合理性。AI很喜欢为了一个小功能引入一个新依赖库。比如明明标准库就有的能力它非让你装一个第三方包。个人项目里依赖越多维护成本越高漏洞风险也越大。所以我在审查时看到新增依赖会特别敏感地回头问AI这个功能不用新库能不能实现很多时候它的回答是“可以但我刚才考虑到XX想省事”。这三关都过了我才会把代码合入主分支。如果没过我会把具体原因告诉AI让它修改。这个“反馈-修改”的循环其实就是你实际在训练一个专属于你的编程模型你给它越多高质量的反馈它在后续生成的代码里就会越贴合你的习惯。5. 常见问题与排查技巧实录5.1 AI写的第一版代码在本地跑不起来这是几乎所有第一次用AI编程的人都会遇到的问题。原因通常不是AI“蠢”而是它缺少运行环境的真实信息。它不知道你用的是Python 3.8还是3.12不知道你系统里有没有装某个动态链接库也不知道你项目的依赖锁文件里有没有它刚用的那个包。解决思路是把环境信息喂给它。我常用的命令是把当前的Python版本、系统版本、包管理文件内容一起贴进对话里。很多时候AI看到requirements.txt里没有某个库立刻就会修正它的写法。还有一个更基础的问题AI生成的代码里可能存在“看起来对但实际是幻觉”的API。它会用一些自己臆想出来的函数名比如os.path.remove这种不存在的方法。遇到这种情况建议先让它“解释这段代码里每个API的用途”它在你追问的时候往往自己就发现幻觉了。5.2 上下文一长AI就“失忆”并开始胡改这个问题在高强度AI编程的第二、第三天最容易爆发。项目文件越来越多、改动越来越频繁AI在单个对话里能记住的东西就那么多。你会发现它越来越频繁地“忘记”你已经告诉过它的约束条件甚至开始重复修改你已经让它改过的文件。我的处理方式是每天开始工作先新开一个对话然后把当前项目的状态小结写进去。比如“项目已完成用户登录功能和文件上传功能现在要加批量导出功能前端在components/export目录下后端在services/export.py导出数据格式参考已有的csv导出模块。”这段小结看起来简单但效果立竿见影它能让AI在短短几十字的上下文中快速进入状态。另外我强烈建议在AI完成每个阶段性任务后让它先把这一步的改动总结保存到一个AI_CHANGES.md文件里后续新开对话的时候把这个文件里最近的记录贴进去。这种做法能有效对抗上下文窗口限制。5.3 AI的安全意识和项目特定约束意识仍然很弱个人开发者的项目里很多人会写一些让自己省事的代码比如测试用的假Token、临时写死的数据库密码。这类东西如果被AI“学习”了——准确说是被它顺着上下文捡起来——它可能会在生成的代码里同样把这类敏感信息硬编码进去因为它觉得“这就是这个项目的风格”。这是我建议在提示词模板里显式加入“不要把密钥、Token写进代码”的原因。AI不会主动判断什么是你个人的隐私边界它只会尽量模仿你给出的代码风格和项目特征。你得明确告诉它边界是什么它才会认真遵守。另外AI生成代码时经常不处理日志输出和错误提示。在个人项目里可能无所谓但如果哪天你想把这个小工具开源别人看到一堆莫名其妙报错体验会很差。所以我在让AI写代码时都会顺手加一句“所有错误情况需要输出可读的错误信息而不是直接crash”。5.4 从“会用AI”到“用得好AI”的进阶路径很多人问要不要报一个AI编程培训班。我的看法是培训班可以上但真正让你变强的不是课程里的“提示词技巧”而是你手头长期维护的那一两个真实项目。因为技巧类的东西网上一搜一大把但你只有在一个有历史包袱、有边界约束、有真实用户的项目里反复打磨才能理解“AI生成代码后真正该做些什么”。如果一定要梳理一个学习路径我的建议是这样的第一步先熟练掌握一门主流语言的基础语法和常用标准库这样你才看得懂AI在写什么第二步学好Git基础操作特别是分支、合并、回滚这是你让AI大胆实验的前提第三步学会看测试用例和写最基本的测试这是你验证AI产出质量的底线第四步找一个小而真实的项目按我前面说的流程去跑一遍“工具选型—提示词—实验分支—审查合入”的闭环第五步遇到具体问题再横向扩展知识比如学一点Docker、学一点CI/CD这些不是AI编程课程的重点但会和你的AI工作流发生化学反应。我个人在实际操作中最大的体会是AI编程确实把“写代码”的门槛降下来了但把“做软件”的门槛提到了另一个层面。以前你只要会写代码就能做出一个能跑的东西现在AI帮你把代码都写了你需要会的是定义问题、拆解边界、验证结果和做权衡决策。这个能力和天赋关系不大完全可以在一次次“让AI写完你再审查”的循环里练出来。如果说有什么建议值得用加粗字体写在文章末尾那就是这句话让AI做足够多的草稿但永远让真正的人握方向盘。 个人开发者AI编程实战：从工具选型到代码审查的完整工作流
1. 内容整体设计与思路拆解1.1 为什么个人开发者必须重新理解AI编程过去一年我自己写代码的方式发生了很明显的变化。以前接到一个需求第一反应是打开编辑器从空文件开始一点点敲现在第一反应是打开AI编程工具先描述清楚我要什么、边界在哪里、有哪些约束让工具先出一版骨架我再review、改细节、补测试。这个过程看上去只是把“写代码”变成了“改代码”但底层的思维模式是完全不一样的。这种变化对个人开发者尤其重要。团队里有架构师、有严格的Code Review流程、有专门的测试环境AI犯的错还有人多层把关但个人项目往往一个人说了算没有人帮你盯着。这时候如果盲目信任AI生成的代码坑会埋得特别深。所以个人用AI编程核心不是“会不会用某个工具”而是“怎么建立一套适合自己的、可控的、可复现的工作流”。我在实践里总结的经验是AI编程本质上是一种“结对编程”AI是那个手速极快但经常犯迷糊的结对伙伴你是那个负责定方向、划边界、做决策的司机。搞清楚这个角色分工后面所有工具选型和方法论都有了解释。1.2 这篇文章适合谁读、能解决什么问题这篇文章的目标读者很明确已经在写代码、但还没系统用过AI编程工具的个人开发者以及那些用了AI但总觉得生成质量不稳定、不知道问题出在哪的人。如果你是完全零基础连Git是什么都不知道这篇文章对你会稍微有些吃力但你仍然可以先把工具选型部分看完选一个图形化界面好用的工具跟着实战部分的思路跑通一个极小的demo之后再慢慢补基础。如果你已经用AI写了不少代码但经常遇到“AI改一处坏三处”“生成的代码一堆bug”“上下文一长就失忆”这些问题那重点看第3章和第4章。这里有我实际踩过的坑和一些具体解法不是那种“你真棒继续加油”的空话。文章的最终目标不是让你成为“提示词工程师”而是帮你建立一套“人机协同”的工作习惯AI负责产出草稿、查文档、写测试你负责设计、审查、决断。2. 工具选型个人可用的AI编程工具全景与选择逻辑2.1 主流工具实测对比市面上的AI编程工具已经很多了我按“使用方式”和“适用人群”大致分了几类先把实际用过的放一张表里后面再逐个说感受工具类型最适合的场景上手成本注意事项GitHub Copilot编辑器插件日常补全、写样板代码低对项目上下文理解有限需要你自己把话说清楚Cursor独立IDE边聊边改、跨文件重构中基于VSCode迁移成本低AI会改到你不想让它改的文件Cline原Claude Dev编辑器插件让AI自己读文件、跑命令、改多文件中高需要API Key费用要心里有数动作比人激进Codex CLI命令行工具在终端里让AI干活、配脚本中对命令行熟的人效率高新手容易懵ChatGPT/Claude 网页版对话界面需求分析、代码理解、写零散脚本低无法直接读本地项目需要复制粘贴且上下文有限Trae、通义灵码等编辑器插件/独立IDE国内网络环境友好、中文支持好低可选效果好但取决于具体版本OH MY PI 类本地智能体自部署智能体隐私要求高、想折腾高配置复杂对个人项目来说维护成本很高2.2 按使用场景选择而不是按排行榜选择很多新手会纠结“到底哪个AI编程工具最强”但我的建议是反过来先想清楚你最常写的代码是什么类型再选工具。如果你是写前端页面、天天调CSS、写React组件那么GitHub Copilot在编辑器里的行级补全体验非常好因为它能根据你正在写的代码实时推测下一行你不需要专门去“对话”它就在那里。这种“无感辅助”对日常敲代码的效率提升是最直接的。如果你经常接到一个需求“帮我看看这个模块为什么跑不起来”或者“把这段老代码重构一下”那适合用Cursor或者Cline这类可以跨文件读取上下文的工具。因为单靠行级补全解决不了这类问题你必须让AI看到整个项目的结构、相关函数、配置文件才能给出有意义的答案。如果你只是想临时写个脚本处理Excel、写个爬虫抓数据那根本不需要在IDE里装什么插件直接用ChatGPT或者Claude的网页版把需求描述一遍拿到代码再在本地跑效率是最高的。我自己现在的工作方式是打开VSCode日常补全交给Copilot类似能力的插件遇到需要理解项目整体逻辑的活切到Cline让它读文件、改代码需要快速验证想法的时候浏览器开一个对话窗口。三个工具各有各的用途不存在“一个工具打天下”的情况。2.3 工具选型的三个判断标准判断一个工具适不适合你我建议从三个维度去评估。第一个是上下文窗口。这里的窗口不是指它能记住多少轮对话而是它能不能真正读取你本地项目的文件。我试过用网页版工具改一个大型项目里某个函数结果只能把相关代码复制粘贴进去一旦文件之间互相引用对话内容很快就超出窗口限制AI开始胡说八道。所以接大项目优先选能直接读文件、自动把相关代码带进上下文的工具。第二个是释放权限的边界。越强大的AI编程工具越会主动替你执行命令比如装依赖、跑测试甚至改文件。这确实方便但也意味着风险它可能在你没注意的时候多删了一行、多装了一个乱七八糟的包。个人项目不像公司项目有沙箱或者专人看护建议只在你有信心回滚的场景里放开权限。第三个是费用结构。很多工具都是订阅费加API调用费的模式看似不贵但如果你天天让它读文件、跑长任务一个月下来账单可能很吓人。个人开发者建议先按量预估一下或者设置一个月度预算别等账单出来才傻眼。3. 提示词与上下文管理AI编程的隐形技能3.1 不要把AI当搜索引擎要把它当新同事很多人觉得写提示词就是“把需求说得更详细一点”这个理解没错但不全面。我更喜欢用一个类比AI是一个刚入职、干劲十足但完全不了解你项目的新同事。你如果只说“帮我把用户登录功能修一下”它只能根据它在训练数据里见过的“登录功能”乱猜结果大概率不符合你的预期。正确的做法是在提问前把新同事需要知道的信息都给它这个项目的技术栈是什么语言、框架、包管理器代码在哪个目录、相关文件叫什么名字你要它做的事是什么最终交付物是什么有哪些约束条件比如不能改某个文件、必须兼容旧版本你希望它怎么输出直接改代码给一个解释写一个测试这些信息不一定全部都有但给得越充分AI的生成质量越高。我自己实测下来的感受是同样是让AI写一个“批量重命名文件”的脚本一上来只给一句话需求它会给一个常见的os.rename实现而如果告诉它“我需要处理1万多个文件路径中包含中文和空格最好支持预览模式我不想执行完才发现有问题”它就会自动考虑到编码问题、路径引号问题和干跑模式。这就是提示词带来的真实差异。3.2 一个可复用的提示词模板我平时写提示词会习惯性地按下面的模板组织。不是每次都要写得这么全但遇到稍微复杂的任务这个模板能帮AI少犯很多低级错误。角色你是一个熟悉{技术栈}的资深工程师。 背景项目位于{目录结构说明}使用{框架/依赖管理方式}。 任务目标{具体要完成的功能或要修复的问题含用户可见行为} 输入/输出示例{如果可能给一两组输入输出让AI准确理解格式} 约束条件 - 不要修改{某些文件或模块} - 保持与现有代码风格一致 - 需要考虑{边界情况如空值、并发、性能} - 不要新增不必要的依赖。 验证方式请给出你如何自测这个功能的步骤或者写一个最小测试用例。这个模板的价值不只是“给AI更多信息”更重要是让AI知道“你的判断标准是什么”。我见过太多人抱怨AI生成的代码不好但其实是从头到尾没告诉过AI“什么叫好”。你给它标准它就按标准干活你懒得给它就按它训练数据里的平均标准干活而这个平均标准往往撑不起一个正经项目。3.3 上下文窗口不够用怎么办AI工具都有上下文窗口超过一定长度之后它会“忘记”前面的内容。个人项目里最典型的问题是一个文件1000行AI只能记住一部分或者你让它改完A文件再让它改B文件时它已经把A文件里的逻辑忘干净了。我试过好几种办法比较实用的有三个第一个是拆分任务。不要试图让AI一次完成一个横跨多个模块的大功能而是把它拆成“首先实现一个工具函数然后写单元测试再接入现有调用点”这种粒度更小的步骤。每完成一步你检查一步、提交一步这样AI的上下文压力小你的审查压力也小。第二个是利用工具的文件引用能力。Cursor、Cline这类插件支持你在对话里直接某个文件或者自动把当前打开文件作为上下文。如果项目特别大你可以先把最关键的入口文件引用进来再让AI顺着入口文件去读它实际依赖的部分。不要一股脑把所有文件都拖进去上下文窗口会被无关代码塞满真正重要的信息反而被挤掉了。第三个是让AI先总结再动手。在让AI改代码之前先让它读一遍相关文件并用几句话复述它对这个文件的理解。这看起来多了一步但能非常有效地避免AI在错误的理解上动手。如果它复述得和你的理解不一致你还能及时纠正而不是等它改完20个文件之后才发现方向错了。4. 实操过程与核心环节实现4.1 从一个需求到一条通过的流程下面我以“给一个Python CLI工具增加--dry-run参数让它可以在正式执行前打印将要执行的操作”为例完整走一遍我平时与AI协作的流程。这个需求不复杂但覆盖了最常见的人机协作环节。第一步我会先用文字向AI描述需求套用前面的模板。给我的AI工具的信息大致是项目是一个Python命令行工具代码在src/目录下入口在src/main.py。 任务新增一个--dry-run标志当用户传入该参数时程序不真正删除文件而是在终端打印“将删除文件: xxx” 约束保持argparse的现有风格不影响其它参数要处理路径中的中文和空格。第二步我会让AI先给出这个功能的实现方案。注意这里不是让它直接改文件而是先在对话框里说清楚它打算怎么做、改动涉及哪些文件。如果它说“我会修改src/main.py新增一个if判断”那基本符合预期如果它说“我会在utils.py里新增模块”我就要确认这个模块是否真的有必要。第三步确认方案后再让它动手改代码。改完后我会让它列出它具体改动了哪些文件的哪些行。这是我自己坚持的一个习惯AI编程最大的风险不是它写不出代码而是它在你看不到的地方改了一堆你不想要的东西。第四步本地跑验证。CLI工具很好验证直接跑python main.py --dry-run看看输出是不是符合预期。如果AI生成的代码有问题不要急着让AI修先看报错信息再把报错原样贴回对话里让它解释原因并给出修改方案。4.2 用git worktree开一条AI专用的实验分支做AI编程时我强烈建议不要直接在主线分支上让它改来改去。AI的修改方向不一定是你想要的试错过程可能很频繁。如果在同一个工作区反复来回折腾不仅历史记录难看有些工具还会因为文件变动太多而大概率失忆。我的做法是用git worktree开一条专门给AI折腾的分支。这个功能可能很多人还不太熟但特别适合个人开发者尝试AI编程时使用。简单解释一下git worktree允许你从同一个仓库里检出多个工作目录每个目录对应不同的分支。这样你可以在原来项目目录不动的情况下在另一个目录拉出一个“AI实验区”让AI在那个目录里随便改。改坏了直接删掉那个目录重建主项目完全不受影响。实际操作大概是这样# 在项目根目录下 git worktree add ../myproject-ai-experiment -b ai-experiment # 这会创建一个新目录 ../myproject-ai-experiment # 指向新分支 ai-experiment内容和你当前分支一样。 # AI在那个目录里改完、测试觉得没问题再回到原目录合并 git worktree remove ../myproject-ai-experiment --force git branch -D ai-experiment这种做法的好处是AI产生的混乱实验不会污染你日常开发的主目录你随时可以在两个目录之间切换对比。坏处是如果你本身不熟悉Git一开始可能觉得麻烦。但我的建议是哪怕多花半天熟悉一下git worktree也值回票价。对经常用AI改代码的人来说这可以算最便宜的安全网。4.3 合入前的代码审查AI写的代码必须过三关AI写完代码不代表工作完成你自己的审查环节才是决定质量的关键。我给自己定了一个规则AI写的代码要过三关才能合入主干。第一关是逻辑正确性。它写的这个功能在正常输入下是否符合预期有没有明显漏掉的边界情况这一关相对容易只要你自己能把握整体需求就能判断个大概。第二关是风格一致性。AI生成的代码往往风格统一但未必和你的项目一致。比如你的项目用单引号它给你生成双引号你的项目函数命名用snake_case它用了驼峰。这些问题不会让程序跑崩但会让后续维护特别难受。我一般会让AI先读一下项目里某个代表性文件再让它模仿这个文件的风格写新代码。第三关是依赖合理性。AI很喜欢为了一个小功能引入一个新依赖库。比如明明标准库就有的能力它非让你装一个第三方包。个人项目里依赖越多维护成本越高漏洞风险也越大。所以我在审查时看到新增依赖会特别敏感地回头问AI这个功能不用新库能不能实现很多时候它的回答是“可以但我刚才考虑到XX想省事”。这三关都过了我才会把代码合入主分支。如果没过我会把具体原因告诉AI让它修改。这个“反馈-修改”的循环其实就是你实际在训练一个专属于你的编程模型你给它越多高质量的反馈它在后续生成的代码里就会越贴合你的习惯。5. 常见问题与排查技巧实录5.1 AI写的第一版代码在本地跑不起来这是几乎所有第一次用AI编程的人都会遇到的问题。原因通常不是AI“蠢”而是它缺少运行环境的真实信息。它不知道你用的是Python 3.8还是3.12不知道你系统里有没有装某个动态链接库也不知道你项目的依赖锁文件里有没有它刚用的那个包。解决思路是把环境信息喂给它。我常用的命令是把当前的Python版本、系统版本、包管理文件内容一起贴进对话里。很多时候AI看到requirements.txt里没有某个库立刻就会修正它的写法。还有一个更基础的问题AI生成的代码里可能存在“看起来对但实际是幻觉”的API。它会用一些自己臆想出来的函数名比如os.path.remove这种不存在的方法。遇到这种情况建议先让它“解释这段代码里每个API的用途”它在你追问的时候往往自己就发现幻觉了。5.2 上下文一长AI就“失忆”并开始胡改这个问题在高强度AI编程的第二、第三天最容易爆发。项目文件越来越多、改动越来越频繁AI在单个对话里能记住的东西就那么多。你会发现它越来越频繁地“忘记”你已经告诉过它的约束条件甚至开始重复修改你已经让它改过的文件。我的处理方式是每天开始工作先新开一个对话然后把当前项目的状态小结写进去。比如“项目已完成用户登录功能和文件上传功能现在要加批量导出功能前端在components/export目录下后端在services/export.py导出数据格式参考已有的csv导出模块。”这段小结看起来简单但效果立竿见影它能让AI在短短几十字的上下文中快速进入状态。另外我强烈建议在AI完成每个阶段性任务后让它先把这一步的改动总结保存到一个AI_CHANGES.md文件里后续新开对话的时候把这个文件里最近的记录贴进去。这种做法能有效对抗上下文窗口限制。5.3 AI的安全意识和项目特定约束意识仍然很弱个人开发者的项目里很多人会写一些让自己省事的代码比如测试用的假Token、临时写死的数据库密码。这类东西如果被AI“学习”了——准确说是被它顺着上下文捡起来——它可能会在生成的代码里同样把这类敏感信息硬编码进去因为它觉得“这就是这个项目的风格”。这是我建议在提示词模板里显式加入“不要把密钥、Token写进代码”的原因。AI不会主动判断什么是你个人的隐私边界它只会尽量模仿你给出的代码风格和项目特征。你得明确告诉它边界是什么它才会认真遵守。另外AI生成代码时经常不处理日志输出和错误提示。在个人项目里可能无所谓但如果哪天你想把这个小工具开源别人看到一堆莫名其妙报错体验会很差。所以我在让AI写代码时都会顺手加一句“所有错误情况需要输出可读的错误信息而不是直接crash”。5.4 从“会用AI”到“用得好AI”的进阶路径很多人问要不要报一个AI编程培训班。我的看法是培训班可以上但真正让你变强的不是课程里的“提示词技巧”而是你手头长期维护的那一两个真实项目。因为技巧类的东西网上一搜一大把但你只有在一个有历史包袱、有边界约束、有真实用户的项目里反复打磨才能理解“AI生成代码后真正该做些什么”。如果一定要梳理一个学习路径我的建议是这样的第一步先熟练掌握一门主流语言的基础语法和常用标准库这样你才看得懂AI在写什么第二步学好Git基础操作特别是分支、合并、回滚这是你让AI大胆实验的前提第三步学会看测试用例和写最基本的测试这是你验证AI产出质量的底线第四步找一个小而真实的项目按我前面说的流程去跑一遍“工具选型—提示词—实验分支—审查合入”的闭环第五步遇到具体问题再横向扩展知识比如学一点Docker、学一点CI/CD这些不是AI编程课程的重点但会和你的AI工作流发生化学反应。我个人在实际操作中最大的体会是AI编程确实把“写代码”的门槛降下来了但把“做软件”的门槛提到了另一个层面。以前你只要会写代码就能做出一个能跑的东西现在AI帮你把代码都写了你需要会的是定义问题、拆解边界、验证结果和做权衡决策。这个能力和天赋关系不大完全可以在一次次“让AI写完你再审查”的循环里练出来。如果说有什么建议值得用加粗字体写在文章末尾那就是这句话让AI做足够多的草稿但永远让真正的人握方向盘。