写Prompt比写代码还重要——一个开发者的AI协作实战手记

0 阅读6分钟

最近在库拉c.myliang.cn上把主流模型都试了一圈,发现一个共识正在形成:AI已经不是"能不能用"的问题了,而是"你用它干了什么"的问题。作为一个每天写代码的人,我这三个月基本把ChatGPT嵌入了开发全流程。今天聊聊哪些场景真香,哪些是坑,以及怎么把Prompt写到让模型一次就吐出你想要的东西。

ScreenShot_2026-04-04_092714_461.png


先说结论:ChatGPT干不了架构师的活,但能把初级开发的活干得飞起

很多人对AI写代码的期待要么太高要么太低。高的人觉得以后不用写代码了,低的人觉得它写的全是bug。

实话说,ChatGPT在编码这件事上的真实水平大概相当于一个水平不错但经验尚浅的中级开发。它能写出让编译器通过的代码,能在已知方案内做最优实现,但遇到需要业务直觉和系统性权衡的架构决策,它基本是在赌。

所以我的定位很明确:让AI处理可重复、有明确边界的编码任务,把需要判断力的决策留给自己。 这个分工一旦建立,效率提升是确定性的。


场景一:写样板代码——这个真的不用自己敲了

每个项目都有一堆重复性代码——CRUD接口、数据模型定义、单元测试骨架、正则表达式、Dockerfile配置。这些东西不难写,但写起来烦,占时间。

我现在这类代码全部交给模型:

用Python FastAPI写一个用户管理模块,包含:

  • Pydantic模型:UserCreate(name, email, phone)、UserResponse(加上id和created_at)
  • 四个接口:POST创建、GET按id查询、PUT更新、DELETE删除
  • 用内存字典模拟数据库,加上基础的输入校验
  • 每个函数写好类型注解和docstring

一分钟出完,逻辑完整,格式规范。我自己写至少十五分钟,还得反复调试类型问题。省下来的时间用在业务逻辑和边界case处理上,这才是真正需要人脑的地方。


场景二:调试——比你翻Stack Overflow快

代码报错是日常。以前我的流程是:复制报错信息→Google→翻三五个帖子→找到解决方案。现在第一步直接丢给模型:

以下代码运行时报错: [贴代码+报错信息] 请分析错误原因,给出修复方案,并解释为什么原代码会出这个问题。

它的优势在于上下文理解能力。Stack Overflow上的回答是针对提问者那段特定代码的,你得自己做迁移适配。而模型能看到你的完整代码上下文,直接给出贴合你场景的修复方案。

不过要注意:复杂bug它也会犯迷糊,尤其是涉及异步、多线程、状态竞争这种问题。它给的修复方案一定要review,不能直接copy paste。把它当第一个帮你分析bug的人,而不是最后一道防线。


场景三:代码审查——低成本的第二双眼睛

一个人写代码最大的问题是自己看不出自己的盲区。逻辑绕进去之后,一些明显的隐患反而视而不见。

我现在的习惯是写完一段核心逻辑之后,让ChatGPT做一次快速review:

请审查以下代码,重点关注:

  1. 1.是否存在潜在的空指针/空引用风险
  2. 2.异常处理是否完整
  3. 3.是否有性能隐患(N+1查询、不必要的循环等)
  4. 4.命名和代码风格是否一致 不要夸我写得好,只说问题。

最后那句"不要夸我,只说问题"很重要。不加这句的话,它会先说一堆"代码整体结构清晰"之类的客套话,浪费输出空间。直接让它挑毛病,效率最高。


场景四:文档和注释——最被低估的用法

程序员最讨厌的事情排行榜上,写文档和写注释永远名列前茅。但这恰恰是AI最擅长的事情之一——因为它本质上就是文本生成任务。

请为以下模块生成API文档,包含:

  • 每个接口的功能描述
  • 请求参数说明(类型、是否必填、默认值)
  • 响应字段说明
  • 至少一个请求/响应示例 格式遵循OpenAPI 3.0规范。

或者更简单的:

为以下函数补充中文注释,解释每个参数的含义、返回值的结构、以及关键逻辑的作用。注释风格遵循Google Python Style Guide。

这种任务AI做得又快又好,而且不会像人一样因为嫌烦而偷工减料。把这类"不难但烦"的工作丢给AI,人的精力就能集中在真正需要创造力的部分。


写好代码类Prompt的三个关键点

根据这三个月的实践,总结出三条经验:

一、把输入输出规格写死。 不要写"帮我写一个排序算法",要写"用Python实现快速排序,输入是int列表,输出是排好序的列表,原地排序,不使用额外空间"。规格越具体,第一次输出的可用率越高。

二、给约束而不是给自由。 "只用标准库""不要用递归""时间复杂度O(n)以内""兼容Python 3.9"——这些约束能有效收窄模型的搜索空间,避免它给你一个花哨但不适合生产环境的方案。

三、贴上下文,别让模型猜。 涉及具体项目的代码,一定要把相关的类型定义、接口签名、已有代码一起贴上去。模型不知道你的项目长什么样,你给的上下文越多,它输出的代码就越贴合你的实际需求。


趋势判断:AI不会取代程序员,但会重新定义"初级程序员"的岗位价值

说句可能扎心的话:如果一个初级程序员的工作内容80%是写样板代码、查文档、做简单CRUD,那这个岗位的议价能力确实在被AI压缩。

反过来说,能把AI用成杠杆的程序员,个人产出会被放大好几倍。 以前一个中级开发一天能干的活,现在一个会用AI的初级开发也能干完。这不是危言耸听,是我身边真实发生的事。

未来的分层逻辑会变成:不是"会不会写代码",而是"会不会指挥AI写代码,以及能不能判断AI写的代码对不对"。审查能力和架构能力的权重会越来越高,手速的权重会越来越低。

对于正在成长的开发者来说,我的建议是:尽早把AI嵌入你的工作流,不是为了偷懒,而是为了把省下来的时间用在提升判断力上。这个判断力,才是AI短期内替代不了的东西。