本文探讨大模型时代程序员如何从代码产出者转变为文档定义者提出文档即代码理念。介绍基于文档的开发流程、人AI结对编程模式、提示词工程技巧及最后10%陷阱应对策略。强调程序员应成为流程设计者通过精细文档引导AI生成代码同时关注安全合规帮助程序员在AI时代保持竞争力。核心目标从“代码产出者”变成“文档定义者”这篇文档不是教你怎么把 CtrlC / CtrlV 换成“让 AI 写代码”而是希望帮你完成一次根本性的角色转换Code is generated, Document is the Source of Truth代码是生成的文档才是真理之源。以前你亲自写代码文档只是代码的“解释说明”经常过期。以后你负责定义核心意图并监管 AI 生成的文档需求、架构、约束AI 负责把文档“编译”成代码。你不再是砌砖的工匠而是画图纸的建筑师。你的核心产出不再是FunctionImpl而是RequirementSpec和ArchitectureDesign。最终目标是在安全合规前提下把“写代码”变成一种“自动化生成”过程人力主要花在需求澄清与拆解把模糊的想法变成清晰的文档架构与边界设计定义 AI 的活动范围文档对齐与验收检查代码是否忠实实现了文档。如果我们真的把这些事情做扎实大概会发生几件很具体的变化文档即代码只要文档改了代码就能跟着变。修改功能不再是“改代码 - 改文档”而是“改文档 - AI 重写代码”。模型无关性只要文档写得够细用 GPT 还是用Qwen区别只在于生成的快慢而不会偏离核心逻辑。知识资产化团队沉淀下来的不再是一堆只有原作者能看懂的代码而是一套套清晰的、可复用的业务逻辑文档。不管你是程序员、测试还是产品、设计师今天都应该大用特用大模型写代码和文档——越早把它融进日常工作越不容易被“会用 AI 的人”替代。年纪大也不一定会被“优化”只要你会用模型完全可以带着一堆 AI 再干几十年。这不是“立刻变成科幻世界”而是一个可以在几个月内逐步感受到的现实改进。为什么要用大模型编程大模型编程LLM‑based Programming的核心变化是从关注“怎么做How”转向“需要什么What”。1.1 一个真实的转变经历2023 年我还在微软时GPT 刚刚兴起大家已经开始尝试用大模型辅助处理一些代码问题。当时微软也在开发基于大模型的 Copilot但受限于模型能力功能还比较基础——只能帮忙添加注释、生成简单的单元测试离真正“会写代码”还有很大差距。然而短短一年多后到了 2024 年底我已经能用 Cursor 完成几乎所有的编码任务。过去一年多我几乎没有真正“手写”过代码。不仅是我我认识的很多程序员也是如此日常工作的重心转向了系统设计、任务拆解和代码 Review具体的实现则交给 AI 模型。加入钉钉后尽管我没有任何 Java 工程经验依然能快速完成开发需求产出的代码质量较高也能很好地与团队现有的代码风格保持一致全倚仗大模型的帮忙。所以我非常确信未来一定是大模型编码的世界学习大模型编程会像学习使用 IDE 一样成为一项最基本的工程师技能。1.2 AI 编程带来的典型变化注意以上场景的效率提升因人而异关键是找到适合你的使用方式。人 AI 结对编程角色与好处在传统软件工程里“结对编程”是指两名开发者在同一台机器上协作一人写代码Driver另一人盯整体设计和问题Navigator两人定期互换角色。收益主要在于更早发现问题、更高代码质量、更快知识传递。在大模型时代可以把日常开发理解为一种“人 AI 的新型结对编程”只是角色从“人 人”变成了“人 模型”在这个模式下写代码不再是你的唯一核心技能你更多要擅长把需求翻译成清晰的 Prompt 和约束条件设计合理的步骤先测试、再改代码、再回归识别模型输出中的风险和幻觉进行二次校对。2.1 会后可以立即尝试的三件事如果你还没有开始用 AI 编程建议从以下低风险任务开始第一次尝试给现有函数补充单元测试选一个你熟悉的、逻辑相对简单的函数复制函数代码对 AI 说“帮我为这个函数写 5 个覆盖边界情况的单元测试”Review 生成的测试修改不合理的 case运行测试根据失败情况调整关键点明确说只写测试不改实现第二次尝试理解陌生代码模块找一个你不熟悉但需要了解的模块把核心类/函数代码给 AI问“这个模块的主要职责是什么关键流程是怎样的”对比 AI 的回答和你自己的理解关键点把 AI 当成导游帮你快速建立宏观认知第三次尝试编写技术方案文档准备好需求描述和关键技术点让 AI 生成文档骨架“帮我写一份技术方案包括背景、方案设计、风险和时间规划”补充业务细节和决策背景关键点AI 负责结构化你负责业务内容预期时间每次 10-20 分钟完成后你会对 AI 的能力边界有基本认知。2.2 新的工作节奏利用“认知缓冲”对抗“代码催眠”在使用 AI 编程时你会发现一个显著的变化键盘敲击声变少了屏幕前的“等待”时间变多了我称之为“受迫性摸鱼”。以前手写代码大脑与手指同步高速运转处于持续的“输出模式”。现在AI 生成输入 Prompt 后需要等待模型生成 30–60 秒这期间你无法进行任何操作。请注意这段“空窗期”不是在浪费时间而是必要的“认知缓冲Cognitive Buffer”。在大模型高速生成大量代码时人类很容易陷入**“代码催眠”**Code Hypnosis状态——即看着代码流淌觉得都对实则大脑已经麻木失去了批判性思维。因此强烈建议大家**“合法化”**这段等待时间强制抽离在 AI 生成的几十秒内允许视线短暂离开屏幕或者清空大脑。这能让你在下一秒 Review 代码时保持“像看陌生人代码一样”的敏锐度。思维预演利用这段间隙跳出具体语法在脑中预演逻辑的边界情况而不是盯着光标发呆。节奏切换从“连续的高频输出”转变为“脉冲式的决策—休息—决策”。给团队的共识在 AI 时代不要用“是否一直在敲键盘”来衡量工作饱和度。一个对着屏幕静默思考、正在进行“认知重组”的工程师往往比一个被 AI 带着跑的工程师更能守住系统的安全底线。模型、工具与技巧3.1 模型选择决策树不要死记某个具体版本最强模型迭代很快。更实用的方式是按决策流程选择使用口诀安全第一复杂度第二成本第三常见模型类型参考常用模型价格使用原则先看安全等级再选模型代码/数据越敏感越应优先选内部合规模型不要依赖单一模型的个人口碑要结合当前任务 实测效果来选择3.2 常见工具形态实际使用时建议团队内统一几种“推荐组合”例如非敏感仓库VSCode 外部高性能模型C3 仓库内部 CLI 内部模型不允许外发代码片段。当然在安全可控和你舍得花钱的情况下你可以使用中转站来使用世界上所有的大模型https://openrouter.ai/https://zenmux.ai/3.3 提示词工程个人 Prompt 模板大模型的“聪明程度”一半来自模型本身另一半来自你给的提示词Prompt。对于经常使用的模型建议为每个模型准备一份固定提示词文件例如claude.md、gpt.md、gemini.md并在会话开始时整体贴入。一个实用的个人 Prompt 模板通常包含这些部分引用文档不要在 Prompt 里口述复杂逻辑请直接引用 URL 或文件路径docs/spec.md让 AI 以文档为准。角色定义你希望模型扮演什么角色结对工程师 / 架构师 / 文档助手等目标与范围这次对话主要解决什么问题允许/不允许碰哪些模块工作方式先问再改、先给方案再写代码、必须生成测试等禁止事项不允许拍脑袋造接口、不允许一次改太多文件、不允许忽略安全规则等输出格式需要列表、代码块、Diff、还是分步骤说明项目特定习惯日志前缀风格、错误码规范、测试框架等现在因为大模型能力的增强已经不需要再写以前那种很长的人设般的提示词了但是约束型和步骤型的提示词仍然很好用。网上也有很多很优秀的模版比如https://cursor.directory/https://github.com/f/awesome-chatgpt-prompts3.4 进阶技巧构建“会自我进化”的 SOP (Real-Time RL Lite)在深入这个技巧之前我们需要先对齐一个工程概念这不仅关乎提示词更关乎工具链的集成 核心概念补齐什么是 Claude SkillClaude Skill 是一个将“大模型的思考逻辑”Prompt/SKILL.md与“传统代码的执行能力”Scripts打包在一起的“能力插件”旨在让通用的 AI 瞬间变成能精准执行特定复杂任务的垂直专家。在高阶 AI 编程中一个成熟的 Skill 通常不止是提示词而是一个**“能力包”**包含两个核心部分1. 大脑 (SKILL.md)这是 AI 的决策指南。它定义了“什么时候用这个技能”以及“怎么分析结果”。_例如_“当用户要求代码审查时请先运行下方的 Python 脚本然后根据输出结果给出建议。”2. 手脚 (Scripts/Tools)这是具体的执行脚本Python/Bash/Node.js 等。_例如_check_coverage.py查覆盖率、format_json.py格式化数据。结构示例my-code-review-skill/这种模式的威力在于你把确定性的逻辑写成脚本传统编程把不确定性的逻辑写成 Prompt大模型编程然后让 AI 自动调度。让 Skill 自我进化 (RL Lite)在 3.3 节中我们提到了静态模板的局限性。**“青春版强化学习”**的核心逻辑是每次任务结束后不只验收代码还要验收 Skill 包本身。操作流程执行 (Execute)让 AI 读取SKILL.md并调用配套脚本执行任务。复盘 (Review)如果任务失败例如脚本报错、或者 AI 对脚本输出的理解有误。进化 (Evolve)修大脑让 AI 修改SKILL.md里的判断逻辑“下次遇到这个报错不要重试直接报错”。修手脚甚至让 AI 直接优化run_linter.py脚本本身“这个脚本处理大文件太慢了请帮我重构一下脚本的性能”。通过这种方式你的**“资产库”**里不仅有越来越聪明的 Prompt还有一套越来越好用的自动化脚本库。实战案例我在使用 Claude Code 时第一次它生成了不带中文注释的代码。我没有只让它重写而是让它更新了自己的 Skill 文件。现在的SKILL.md里自动多了一行Rule 5: All strictly business logic must have simplified Chinese comments explain the ‘Why’, not just the ‘How’.从此以后我再也不用在这个问题上浪费口舌。即使哪天换了模型换了新人只要这份 SOP 还在团队的战斗力就能在几分钟内恢复 80%。我的极速版Gemini.mdProtocol Selection RulesFrom now on, please adhere to the following protocols based on the task type:Medium/Large Code Tasks: Refer to/Users/wuyue/Documents/RIPER-5.mdSmall Code Tasks: Refer to/Users/wuyue/Documents/RIPER-LITE.mdDocumentation Tasks: Refer to/Users/wuyue/Documents/RIPER-DOC.mdPlease try to communicate with me in Chinese as much as possible.而且你也可以在和大模型的对话和工作的过程中根据自己的习惯和喜好命令大模型帮你更新对应的claude skill这样也可以满足懒人的需求比如这一版Gemini.md就是我让gemini写的。这里还有一些claude skill的例子大家熟练了之后可以作为参考。https://github.com/ComposioHQ/awesome-claude-skills基于文档的开发流程 (Spec-Driven Development)什么是 Spec-Driven Development (SDD)?Spec-Driven Development (SDD) 是一种软件开发方法论强调在编码开始之前编写详细、结构化的规格说明书Specifications通常用于指导 AI 编程代理。它采用分阶段的方法首先明确用户需求和意图接着创建技术方案将工作拆解为微小的、可审查的任务最后逐一实施这些任务。这一过程旨在通过提供清晰的开发蓝图减少猜测和返工从而显著提高代码质量、可控性和可预测性。这是本指南推荐的标准作业流程。它的核心在于**严禁在没有文档支撑的情况下直接修改代码。**让大模型完全基于文档以文档为唯一核心这样程序员只需要控制文档就可以约束大模型就可以控制代码的质量保证下限。4.1 核心理念文档即源码 (Doc as Code)在 AI 编程时代自然语言文档就是你的“源代码”而 Java/Python 代码只是某种“编译产物”。Source Code:requirements.md,api_spec.md,architecture_decision.mdCompiled Binary:UserService.java,main.pyCompiler: LLM (Claude, GPT, Qwen)4.2 标准工作流 (The SDD Workflow)Phase 1: 意图定义与文档生成 (Intent Spec Generation)Step 1 (Human): 提供简要的意图 (Intent) 和上下文 (Context)。Prompt: “我想给结算流程增加 VIP 折扣参考现有的 Coupon 逻辑。”Step 2 (AI - Architect Agent): 让 AI 草拟详细的技术文档 (Spec)。Result: AI 生成了docs/tasks/vip-discount.md包含修改步骤、接口定义和数据流。Step 3 (Human - Sign-off):核心环节你必须阅读并修改这份文档确保 AI 理解了你的真实意图。**只有当你“锁定” (Sign-off) 这份文档后才能进入下一阶段。**这里的文档就是你对 AI 下达的“法律指令”。Phase 2: AI 编译 (AI Implementation)动作将上述文档喂给 AI。Prompt: “请阅读feature-xxx.md并严格按照其中的 Steps 生成代码。”结果AI 生成代码 Diff 或直接修改文件。Phase 3: 文档验收 (Verification Alignment)动作检查 AI 生成的代码。关键点如果发现代码逻辑不对不要直接动手改代码也不要只在对话框里骂 AI。正确做法回到feature-xxx.md修改描述得不清楚的地方比如增加一个约束条件然后让 AI“重新编译”Re-generate。原因这样能确保你的文档永远是最新的且下一次或换一个模型还能生成正确的结果。4.3 Demo 示例一用日志 AI 做 Debug内部项目只能使用内部工具 iflowQwen3 coder先用大模型添加全流程日志推送代码并且部署让大模型提交代码的好处就是可以帮你自动生成commit和自动解决一些落后和冲突的问题比如运行测试然后获得日志再把日志喂给大模型4.4 Demo 示例二从开源项目到“文档 小改动”开源项目可以使用任何工具例如claude codeclaude4.5, codex gpt 5.1, kilo codegemini3等使用大模型A(codexgpt5.1)来生成文档花费了大约八分钟注意token消耗这都是钱提出修改需求让大模型输出详细的修改文档让大模型Bclaude code claude 4.5阅读文档和项目让他说明这份文档是否足够帮助修改代码以及有什么可能的问题。让大模型A根据意见修改文档如果你有耐心可以反复让多个大模型互相review直到他们都不再有意见。让大模型B开始实施代码让大模型A和大模型B分别review最好再加上一个新的大模型C一起review然后根据意见修改文档和代码。这样反复直到你和大模型都没有更多意见。让大模型补充大量的日志并且使用专用的日志管理器来方便进行debug。推送和测试。让大模型提交和推送再也不用担心推错文件、用错git命令、或者编不好commit了。最后参考demo示例一在pre环境进行全流程/回归测试捕捉对应日志再喂给大模型。4.5 进阶图景文档是 AI 智能体之间的“通信协议”(Protocol of Agents)我们常把文档看作是“给人看的”但在大模型时代文档有了全新的身份不同 AI 智能体之间的 API。这开启了一种全新的团队协作模式以后不再是你和我沟通而是你的大模型和我的大模型进行沟通人类只需要做 Review 和信息确认。这种“Agent-to-Agent”的协作可以覆盖软件工程的全链路产品 - 开发 (PM AI Dev AI)产品经理口述需求让“产品 AI”生成一份结构化极强、无歧义的Requirement_Spec.md。开发人员不需人工翻译需求而是直接把这份文档喂给“架构师 AI”自动生成API_Design.yaml和DB_Schema.sql。开发 - 开发 (Backend AI Frontend AI)后端开发定义好接口文档API_Spec.md。前端开发的 AI 读取该文档自动生成 TypeScript 类型定义、Mock 数据和 API 调用代码。后端改了接口更新文档前端 AI 自动感知并重构调用逻辑。开发 - 测试 (Dev AI QA AI)开发提供Design_Spec.md和API_Spec.md。测试人员的 AI 读取文档自动生成Test_Cases.json和自动化测试脚本。人类只做验收人类不再去写每一行测试代码而是审核测试用例覆盖了哪些业务场景。这一模式的核心价值消除“翻译损耗”传统模式下人脑 - 口述 - 人脑信息层层衰减。新模式下AI - 标准文档 - AI信息以数字精度无损传递。各司其职的维护每个人只负责维护自己领域的文档。当需求变更时上游更新文档下游让 AI 重新跑一遍 Diff立刻就能完成全链路的对齐。文档活化文档不再是躺在 Wiki 里的死尸它是连接产品思维、代码实现与测试验证的活性媒介。常见陷阱与对应策略陷阱❌ 错误做法✅ 正确做法上下文腐烂持续保持在一个对话session中很久导致上下文太长太宽泛模型注意力丢失。尝试多使用compact指令并且在解决完一个问题后就使用clear指令清理上下文。目标漂移“帮我优化这个函数”结果 AI 重构了整个类“只优化函数calculateTotal不做任何其他的变更集中于此函数一点。”幻觉/瞎编接口直接使用 AI 提到的StringUtils.sanitize()方法先用 IDE 搜索确认项目里是否真有这个方法不存在就反馈给大模型要求它重新给方案。过度信任只看 AI 的文字解释“我已经修复了空指针问题”每次都亲自看 Diff检查是否真的加了空值判断并运行相关测试验证。每次都让执行大模型和其他大模型进行汇总回报和review。一次要求太多“帮我实现用户注册、登录、权限管理和日志记录”拆成多个小任务每次只做一个功能模块尤其是qwen3和GLM4.6等能力稍弱的模型。规则过拟合因为一次特殊情况骂了 AI导致它在 SOP 里写死了一条极其严苛的规则如“禁止使用任何第三方库”导致后续任务卡死。定期 Review 你的 Prompt/SOP 文件*。像重构代码一样重构 Prompt删除过时或太死板的规则保持指令的通用性。核心原则AI 是很厉害的实习生不是无需审核的高级工程师。进阶防守对抗“复杂度熵增”与“最后 10% 陷阱”很多新手在使用 AI 编程时容易陷入一种线性的乐观“既然 10 分钟能写完前 50%那剩下 50% 肯定也很快。”但真实的大模型开发曲线是非线性的。为了避免项目在收尾阶段崩盘我们需要引入一套**“防守型开发策略”**。5.1 认清“倒 J 型”曲线在传统编程中难度通常是渐进的。但在 AI 编程中存在一个显著的**“最后 10% 陷阱”**0% → 90%蜜月期从零开始生成新功能非常快AI 对全新的、独立的逻辑处理得极其完美。90% → 100%深水区当功能需要收尾涉及到复杂的上下文、边缘 Case 修复、以及与旧逻辑的耦合时AI 的表现会断崖式下跌。警惕往往最后的 10% 的功能完善很有可能需要占用整个开发周期20% 至 30%的时间。在这个阶段代码的复杂度熵增极快。一个微小的改动比如修个 UI可能导致后端核心逻辑崩塌Regression。如果你此时还在盲目追求速度大概率会陷入“修一个 Bug生出三个新 Bug”的死循环。5.2 核心策略建立“文档-代码同步记录仪” (ChangeLog)为了对抗混乱我们不能只依赖 Git 的 commit而需要建立一份由 AI 自动维护的 ChangeLog。更重要的是这份日志必须追踪文档与代码的一致性。它的核心价值在于1. 认知对齐当开发了两天后最早的需求约束会被遗忘。ChangeLog 帮你回忆“我们根据哪个版本的文档做了哪些改动”。2. 法医级溯源如果代码逻辑和文档不一致ChangeLog 能帮你判断是“文档改了没同步代码”还是“AI 只有幻觉”。关键原则Code follows Doc: 所有的 ChangeLog 必须注明依据的文档版本/文件名。No Doc, No Code: 如果 ChangeLog 里出现了一条没有对应文档支撑的代码变更这就是危险信号。5.3 实战落地用 Skill 强制执行 (Auto-Flight Recorder)与其靠人工自律去写日志这很难坚持不如利用我们在 3.4 节提到的 Skill 技术把这个动作变成强制执行的肌肉记忆。我们只需做两步配置就能让 AI 变成自带“黑匣子”的靠谱副手。第一步准备“手脚” (脚本)创建一个简单的 Python 脚本scripts/log_change.py用于标准化追加日志。# scripts/log_change.py第二步配置“大脑” (Prompt / SKILL.md)在你的 Skill 定义文件或系统 Prompt 中写入死命令不给 AI 偷懒的机会。## Rule: Automatic Flight Recording(自动飞行记录仪)效果 从此以后你只管发号施令。AI 在修完 Bug 后会自动汇报“已修复且潜在风险点已自动归档请查看日志。”5.4 最后的防线高频存档与对话归档除了自动日志在深水区开发时还必须遵守两个铁律1. 高频暂存 (Save Points)在最后 10% 的阶段每一次AI 成功运行代码后立刻git add .和git commit或者暂存。不要等到功能完美才提交。Git 是你的“后悔药”当你发现 AI 把逻辑改乱时必须能毫无心理负担地回滚到上一次“正常呼吸”的状态。2. 对话归档 (Session Dump)推荐把所有与 AI 的关键对话记录保存下来导出为 Markdown 或 PDF与代码库一同归档。这是为了解决“死无对证”的问题如果是 AI 误解了需求导致的问题你可以通过翻阅对话记录把当时的 Context 重新喂给新的模型在“还原现场”的基础上进行修复而不是重新瞎猜。安全与合规模型接力与仓库分级在企业环境中“用大模型”最容易踩坑的安全问题是把敏感代码或数据不加控制地丢给外部模型。6.1 简化版分级思路当然还有给不同的cli、大模型和插件提供igonre来阻止他们阅读敏感文件。6.2 模型接力推荐范式为了兼顾安全与效果可以采用“模型接力”1. 内部模型先读 脱敏用内部模型阅读 C3 代码生成架构说明 / 时序图脱敏后的伪代码或接口描述。2. 外部模型基于脱敏信息生成方案 / 新代码把伪代码、接口签名和非敏感上下文交给外部高性能模型让它生成实现骨架提供重构建议写测试样例。3. 内部验证与落地回到内部环境由开发者和内部大模型对照原代码落地实现再用内部模型或人工做 Review 与回归测试。6.3 C3 场景最小 Checklist示例在 C3 仓库中使用 AI 前可以自查我是否确认当前用的是内部/合规模型而不是公网接口是否避免把以下内容发往外部完整关键业务实现明文密钥、账号密码、手机 / 身份证等个人信息客户业务数据样本。是否添加了ignore文件并且强制要求cli使用。若确需借助外部模型是否先通过内部模型或手工做了脱敏 / 抽象只发伪代码和接口说明外部模型生成的代码是否经过了内部 Review 和测试再合入你的责任流程设计者而不仅是代码作者结合前面的内容可以把大模型编程理解为两层职责1. 个人层面养成熟悉模型能力边界的习惯在日常开发中主动采用测试优先 分步实现 明确约束的工作流2. 团队层面设计并推广一套适合团队的AI 使用规范和安全 Checklist为不同仓库、安全等级选好默认模型和工具组合把典型案例一次成功的 refactor、一次复杂 bug 的 AI 辅助排查沉淀成团队经验如果说传统编程时代你的核心资产是“你脑子里的经验”和“你写下的代码”那么在大模型编程时代你最宝贵的核心资产将变成**这一整套“文档驱动的开发体系”——包括精细的需求文档、架构设计、Review 标准以及那份会自我进化的 Prompt/SOP 库。**即使哪天换了模型换了新人只要流程和SOP 还在团队的战斗力就能在几分钟内恢复 80%。这份文档只是一个起点真正的价值会来自你在实际项目中不断试错、总结、微调的那套你们自己的流程。附录常见疑问 FAQQ1: 用 AI 写的代码出 Bug责任算谁的A: 算你的。AI 是工具你是使用者和最终 Review 者就像用 Stack Overflow 复制的代码出问题责任也在你。最终上线的代码质量由你负责。Q2: 学习 AI 编程会不会让我的编码能力退化A类比思考用 IDE 自动补全不会让你忘记语法但会让你不再记忆 API 细节。关键是理解原理而非记忆语法。AI 编程会让你更少关注怎么写一个循环更多关注系统架构是否合理编码能力不会退化但能力重心会上移Q3: 我的代码会不会被模型拿去训练泄露给别人使用企业内部模型不会数据不出内网使用外部商业 API如 OpenAI、Anthropic大部分商业服务承诺不用 API 数据训练模型但需查阅具体服务协议使用免费在线服务可能会务必查看用户协议最佳实践C3 代码只用内部模型C1/C2 代码可用外部 APIQ4: AI 总是给出错误答案是不是不可用A需要调整使用方式1. 明确约束不要问帮我写个登录功能而要说用 Spring Security JWT 实现登录Token 有效期 2 小时2. 分步验证不要一次生成整个模块而是先让 AI 给方案你确认后再分步实现3. 主动纠错发现错误立即反馈给 AI“这个方法不存在请使用项目里已有的 XxxUtils”Q5: 用了 AI 之后我还需要学习新技术吗A必须学而且可能要学得更快。AI 可以帮你快速理解新框架的基本用法“帮我解释 React Hooks 的原理”生成示例代码加速上手但 AI 不能替代你的技术判断力和架构能力反而因为 AI 降低了实现成本你会有更多精力去探索新技术。Q6: AI 能完全取代程序员吗A不能至少在可预见的未来不行。AI 在很多重复性、模式化、实现层面的工作上确实已经可以做到比普通工程师更稳定、更高效但它有几个天然短板很难真正理解那些含糊、暧昧、不断变化的产品需求只能根据你给的描述去“猜”无法主动协调多个子系统、多个 Sub AI 以及跨团队沟通它只能在你设计好的流程里执行最关键的一点它没法为线上事故和业务决策背锅也承担不了合规和安全责任。所以更现实的图景是能熟练驾驭 AI 的工程师会替代不会用 AI 的工程师而不是“AI 整体替代所有程序员”。你的不可替代之处在于理解业务、拆解问题、设计流程以及为结果负责——AI 帮你干活但短期内还抢不走你的饭碗。Q7: 使用大模型效率提升了团队是不是应该承担双倍的需求吞吐量A: 这是一个需要高度警惕的“效率陷阱”。虽然 AI 加快了“编码Coding”的速度但它并没有缩短“思考Thinking”、“审查Reviewing”和“验证Testing”的时间。相反AI 生成代码的速度越快代码审查的密度要求就越高。如果因为 AI 写得快就盲目将需求吞吐量翻倍会导致两个严重的后果1. “泡沫代码”堆积AI 极易生成“看起来能跑但逻辑脆弱”的代码。如果没有足够的人工 Review 时间这些代码会迅速变成难以维护的“技术债”。2. 风控防线失效当排期被压缩到只能“由 AI 生成并直接提交”时工程师实际上失去了对系统的掌控力。一旦发生线上故障修复成本将指数级上升。结论AI 节省下来的时间不应被全部转化为“更多的功能数量”而应被重新投资到**“更高的代码质量”和“更完备的测试覆盖”**上。这才是实现降本增效降低维护成本增加开发效率的正确路径。注以上图片均由Gemini3制作内容由GP5.1、Gemini3、Qwen生成。开源项目由Claude4.5和GPT5.1操作。流程以及为结果负责——AI 帮你干活但短期内还抢不走你的饭碗。Q7: 使用大模型效率提升了团队是不是应该承担双倍的需求吞吐量A: 这是一个需要高度警惕的“效率陷阱”。虽然 AI 加快了“编码Coding”的速度但它并没有缩短“思考Thinking”、“审查Reviewing”和“验证Testing”的时间。相反AI 生成代码的速度越快代码审查的密度要求就越高。如果因为 AI 写得快就盲目将需求吞吐量翻倍会导致两个严重的后果1. “泡沫代码”堆积AI 极易生成“看起来能跑但逻辑脆弱”的代码。如果没有足够的人工 Review 时间这些代码会迅速变成难以维护的“技术债”。2. 风控防线失效当排期被压缩到只能“由 AI 生成并直接提交”时工程师实际上失去了对系统的掌控力。一旦发生线上故障修复成本将指数级上升。结论AI 节省下来的时间不应被全部转化为“更多的功能数量”而应被重新投资到**“更高的代码质量”和“更完备的测试覆盖”**上。这才是实现降本增效降低维护成本增加开发效率的正确路径。注以上图片均由Gemini3制作内容由GP5.1、Gemini3、Qwen生成。开源项目由Claude4.5和GPT5.1操作。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】