2026中高级程序员生存指南：接地气的Claude Code实战手记

JunoCode
2026年1月11日
35 阅读
AI编程

“让AI去写那些该死的代码，你只负责架构和技术决策。”

开发环境: Linux/WSL AI编程工具: Codex/Claude Code(简称cc)

官方文档永远是最好的 👉 https://code.claude.com/docs/en/setup 但看我这个才能速成

关于cc 和 codex的所谓的高级技巧（什么MCP，SKILL）不赘述其实是太懒了（这些玩意本质也是用提示词去激活、驱动AI的Agent、Tool Call能力去动态增加额外约束，或通过调用工具来扩展能力），如果只作coding用，99%的场景都用不着（甚至有副作用：污染上下文，影响性能）...

对于大模型的应用，提示词仍然是核心！

从第一性原理触发，关于AI编程的，你真正需要的是：

  • 搞清楚要开发什么？细节？目标？
  • 下达明确、清晰指令！

使用AI编程后的一个效果是，基本上梳理清楚需求，业务流程、逻辑，有了大致思路之后，写完提示词，就相当于开发完了

插图

以下示例提示词，都是真实的、生产级、可直接套用的提示词！

场景一：写接口 - 基于SQL DDL/Model文件去生成CRUD接口

由于AI不知道表的字段，所以将SQL文件放到项目里（如果已有Model文件则不需要），方便让AI再需要的时候去读

当有参考范式的时候：

@api/admin/controller/DiscountController.php 的 manualPush 方法/接口，用于给指定用户发放优惠券的, 现需要在此基础上新增、迭代这个接口，使其支持给 某一个或多个标签下的多个用户 发放优惠券（确保其他已有功能不变、正常）；相关表结构可参考 @data/sql/user_tags.sql；一步步分析、思考、实现！

有特殊要求的时候：

在 @api/operation/controller/DashboardController.php 新增一个接口，实现对商品的查询、统计，并返回以下数据：
1.总销量数量
2.总销量金额
3.近7天的销量和金额
=== 前端无需传参，需考虑性能；一步步分析思考实现!

发现没有？核心结构无非是：完成任务需要的前置知识、背景 + 清晰地描述当前需要开发的功能（给出参考文件、上下文） + 输出风格的约束

人工审核AI代码的步骤不要省略，不然可能不可控，至少需要看下AI的实现思路是不是对的，代码风格是不是你想要的；否则越堆积越多，可能失控

使用GPT-5.2(codex) 或者 Claude opus 4.5(claude code) 基本可以一次完成，不需要更改；国内模型、AI工具不保证

场景二：想要中断任务，下一次在继续的时候: 上下文已经累积得太长，或想要再确认、优化方案

将当前工作任务、进度保存到 docs 下；同时告诉我下一次再继续执行这个开发任务，要如何给AI下指令？

场景三：生成接口文档

在写完接口之后，继续让AI生成文档

可以在开发完接口后直接追问：

更新这个接口文档 到 @docs/operation_dashboard_api.md

或者新建的会话:

@api/admin/controller/CooperationcontentController.php 以上是后台管理模块用到的控制器-方法/接口，生成对接的接口文档到 api_docs 目录下，方便前端同学对接

或者生成方便导入api工具的接口格式：

@api/pos/controller/CouponController.php 生成基于这个控制器里的方法/接口的**openapi 3.0+ 格式的JSON**到 docs/api 目录下！

场景四：根据AI生产的接口文档继续让AI生成前端页面

在app/insight目录下新增一个页面，基于 @docs/api/operation_dashboard_api.md 对接、实现这些接口的能力！布局样式使用 Claude-front-end-design skill

场景五：扩展、优化表结构

@data/sql/questionnaire.sql 新需求：需要在用户填完问卷、提交后送优惠券（送的券的数量可能1张或多张）; 给这个问卷表扩展合理的字段，直接新增DDL到这个文件！避免过度设计！

场景五：分两步，先规划出技术方案再让AI开发

当任务流程较为复杂，或者一次性要开发的、相关联的接口比较多的时候，先根据自己的描述（可能漏细节） 或者 PRD，让AI（可以是外部AI，不需要是AI Code Agent）整理、精简为适合AI阅读的MD格式文档！

然后再放到cc里：

根据表结构: @data/sql/mall.sql 以及 需求文档: @docs/看板接口需求v2.md (记住：只统计 external_order_no 为空的订单，也就是说不统计线下的、以及外部推送过来的订单) 在 api/operation/controller 目录下，新增相关控制器，并实现这些接口！ ===一步步分析、思考、实现！

场景六：强制代码风格约束

@docs/module_design.md 为事先准备好的文档，里面是具体约束AI的代码要求

参考 @data/sql/discount_coupon.sql 以上优惠券表结构，代码风格遵循 @docs/module_design.md，在 api/open/controller 下新增一个控制器、一个接口：开放查询优惠券列表给第三方，条件：只有 status && is_allow_third_get 为1 的优惠券才开放查询（如果有些条件通过sql不好维护或者性能低，则用代码来处理！）；需要支持分页数据；不需要返回的字段：status created_at updated_at；一步步分析、思考、实现！

当然以上用例绝对不足以覆盖实际工作中的所有场景，但核心思想掌握了，就能很容易做到举一反三了。而且以上案例更多是针对既有旧项目（legacy项目）的维护、迭代，如果是新项目，建议使用全栈框架（Nextjs, Laravel）一把梭！前后端代码放一起，AI一起理解、一起更新，完全交由AI，完全文档驱动，完全不用这样「小心翼翼」，直接起飞！ 🚀

我当然也清楚知道，现实世界往往更加复杂，现实中架构、算法还真不一定比业务更「高贵」，落地执行的复杂度也只有一线程序员能懂，特别是很多架构师、技术总监的方案，如果直接扔给AI，根本「吐」不出想要的东西。那些方案大都是无法落地的PPT、Excel、导图...

AI时代，程序员们一定要从日常重复的CRUD中解放出来，去思考、去做更有价值的事情！