★ FEATURED ARTICLE 我写代码有些年头了从最早用编辑器敲HTML到后来用各类全栈框架做项目工具换了不知多少茬。但真正让我觉得“回不去了”的是最近这两年AI编程进入日常之后的变化。AI编程不再是演示台上的花架子它真的能帮我从需求聊到部署、从报错聊到修复像一个随叫随到的结对编程搭子。这篇内容我想把自己从入门到实战这一路的经验完整整理出来。如果你正准备入坑AI编程或者已经在用但总觉得效率没提上来可以把它当成一份参考地图照着走能少踩不少坑。先说清楚一件事AI编程不是“你把需求打字发给它它把代码吐给你”这么简单。如果只是这样用你会发现它生成的代码要么编译不过要么功能对不上要么夹带着一堆看不懂的写法。真正好用的AI编程是把“人提需求、AI写代码”变成“人拆需求、AI给方案、人验证、AI迭代”的协作闭环。这篇文章会从工具选型、提示词方法、实战项目复盘、避坑经验、工作流搭建五个维度展开最后聊几句我个人的真实体会。1. 先别急着写代码想清楚AI编程到底改了什么1.1 一个老程序员最真实的感受我最早接触AI编程的时候内心是有点抵触的。因为写代码这件事本来就是一个“把混乱需求变成严谨逻辑”的过程这个过程里有大量判断我不太相信一个对话窗口能接得住。但后来我试了一个很简单的任务让它帮我写一个解析日志文件的Python脚本。我描述完字段格式它几十秒就给了完整代码我拿真实日志一跑居然能出结果。那一刻我意识到AI编程真正改变的是“从想法到代码原型”的速度。以前我写一个工具脚本要查文档、试语法、调格式少说一小时现在只要把需求描述准确第一版代码几分钟就能出来。省下来的时间我全部花在了更重要的事情上想清楚边界条件、设计数据流、写测试用例、做代码审查。所以我的第一个观点是AI编程不是替代程序员而是把程序员的精力从“敲键盘”挪到了“做判断”。你判断得越清楚AI帮得越到位你判断得越模糊它给你的代码就越像猜谜。1.2 哪些人适合用AI编程哪些人暂时不适合先说结论有基础的人用AI编程是如虎添翼零基础的人用AI编程是如虎添乱。这话有点绝对但真实情况确实如此。适合用AI编程的人至少具备三个能力能看懂代码的大致逻辑能判断结果对不对能描述清楚自己的需求。哪怕你只写过几百行代码只要这三项过关AI就能帮你把开发效率拉升一到两倍甚至更多。我看到很多团队里的新人刚入职就被要求用AI编程工具干活他们反而最容易卡住——因为看不懂AI给的代码出了问题也不知道怎么描述给AI听最后只能靠反复碰运气。零基础的人能不能从AI编程入门可以但不建议一上来就让它写整个项目。更稳妥的路子是先学最基础的语法和逻辑用AI当“随堂老师”帮你解释概念、出练习题、批改思路等你有了基本的代码阅读能力再让它帮你写项目。我见过一位完全没写过代码的同事硬是靠AI编程工具做了一个内部小工具也跑起来了但他自己承认里面有将近一半的逻辑他不完全懂上线之后每次改需求都像拆炸弹。这就是基础不牢的后遗症。1.3 别把AI当搜索引擎用很多人用AI编程工具还是搜索引擎的习惯遇到问题把报错信息复制进去把问句原封不动抛过去得到答案后复制粘贴跑不通就再问一遍。这种用法不是不行但效率极低而且容易把上下文搞得一团糟。搜索引擎的逻辑是“找答案”AI编程的逻辑是“协作求解”。同样一个报错搜索引擎给你的是别人的踩坑记录而AI编程工具能拿到你的报错、你的代码片段、你的依赖版本、你的运行环境综合这些信息给一个针对性修复方案。前提是你得把这些信息作为上下文喂给它。我用AI编程工具一年多最大的习惯转变就是不再问“这个报错怎么解决”而是问“我的项目是做什么的用了什么技术栈这个文件的功能是什么报错出现在哪一行我已经尝试过什么下一步我该往哪个方向排查”。这样一段描述下来AI给你的答案质量完全不一样。2. 工具怎么选三条技术路线的对比2.1 三种路线补全、对话、智能体市面上的AI编程工具看起来五花八门骨子里其实就三条技术路线。理解这三条路线你选型的时候就不会迷失。第一种是“代码补全型”核心能力是“你写到一半它帮你接下半句”。它嵌在编辑器里光标停下来就自动给建议按下Tab就接受。这类工具擅长写模板代码、重复性代码、常规函数和你的编辑器深度绑定。优点是侵入性低你正常写代码它默默给你提速缺点是它比较被动你不能让它去改一个很远文件里的逻辑。第二种是“对话生成型”核心能力是“你描述需求它给你完整方案或完整文件”。你跟它对话它生成代码、解释代码、修改代码你可以把整个项目代码贴给它让它分析。这类工具适合做新功能、写独立模块、重构代码片段。优点是灵活、能力强缺点是需要你自己管理上下文聊着聊着它忘了前面的约束是很常见的事。第三种是“智能体执行型”核心能力是“你给它一个目标它自己操作电脑完成任务”。它会读项目目录、改文件、跑命令、看报错、再改文件像一个小实习生帮你干活。这类工具最适合那些边界清晰、有明确验收标准的任务比如“把这个目录下所有图片压缩到200KB以内”“给这个函数补上单元测试”。优点是自动化程度高缺点是任务一复杂它就容易失控而且它在终端里执行的命令你要有足够的辨别能力。2.2 我现在的组合与理由我现在日常用的组合是一个代码补全型的编辑器插件加上一个对话生成型的大模型客户端偶尔用智能体型工具处理大批量的机械化任务。没有统一用某一个全家桶因为它们在各自场景下的表现确实不一样混用能取长补短。日常写业务代码的时候补全型插件帮我接函数体、写重复模板、补注释非常顺畅。遇到需要设计思路、写新模块、排查疑难Bug的时候我会切到对话窗口把相关代码贴进去和它反复讨论方案。批量处理任务比如一次给几十个文件加日志、统一替换某个废弃API的调用方式我会交给智能体型工具跑一遍跑完再逐个review改动。选型上我有一条原则没有哪个工具是万能的关键是搞清楚你当前最痛的点是什么。如果你最大的痛是“每天写一堆重复代码”就选补全型如果你最大的痛是“拿到需求不知道从哪下手”就选对话型如果你最大的痛是“杂活太占用时间”就试试智能体型。2.3 环境准备与第一句Prompt不管你选哪条路线准备工作都很简单装一个顺手的主流IDE注册好AI编程插件账号联网即可。不需要额外搭什么环境不需要配什么参数。很多人卡在“我需要配一个完美的配置文件才能开始”其实完全没必要。我的建议是第一次用AI编程工具不要搞复杂项目就让它帮你写一个小脚本练手。比如让它写一个“批量把CSV文件里的空值填0并输出新文件”的脚本。这个任务足够具体、足够短能让第一次接触的读者直观感受到AI编程的节奏也能暴露你在描述需求上的短板。第一句Prompt可以这样写我要写一个Python脚本功能是批量处理一个文件夹下的所有CSV文件。 每个CSV文件里如果有空值就把空值填充为0处理完后保存为“原文件名_filled.csv”到同一个文件夹。 请给出完整代码并在关键步骤加注释。就这一段话AI生成代码后你复制到编辑器里运行大概率能跑通。这就完成了你AI编程的“Hello World”。3. 核心能力是提问提示词工程入门与进阶3.1 一个能用的提示词长什么样提示词就是你和AI编程工具沟通的“输入语言”。它不需要什么神秘语法但它有一个固定的逻辑结构角色、任务、约束、输入输出示例。缺了哪一块AI的产出就会打折扣。我常用的模板是你是[角色]请帮我[任务]。 要求 1. 使用[技术栈/语言] 2. 输入是[输入格式]输出是[输出格式] 3. 不能使用[你不想用的依赖/特性] 4. 需要处理[边界条件比如空值、超长文本、文件不存在] 5. 关键逻辑要加注释 示例 输入... 期望输出...举个例子你有真实效果。我之前让AI写一个“解析Nginx访问日志并统计每个URL的访问次数”的函数如果只写“帮我写个日志统计脚本”它给出的代码大概率会假设一个根源格式跟你手上的日志对不上。但如果按模板写你是Python开发工程师。请写一个函数解析以下格式的访问日志行 IP地址|访问时间|请求方法|请求路径|状态码|User-Agent 输入是一个日志文件路径函数需要读取文件统计每个请求路径的出现次数按次数降序返回一个列表。 如果某一行格式不对跳过并累加到一个错误计数变量里最后把错误计数也返回。 请返回完整的函数代码和调用示例。这样写AI就知道该用什么数据结构、怎么处理脏数据、函数签名该长什么样。它给你的东西基本就是直接能跑的。3.2 从模糊到精确需求描述三要素很多时候AI给出的代码“好像对但实际没用”根源在于需求描述太模糊。我总结了三个要素写提示词的时候对着检查一下能省一大半返工时间。第一个要素是“明确输入和输出”。输入是文件、字符串、接口还是数据库表输出是要数组、对象、文件还是直接打印你把这个说清楚AI就不用猜。第二个要素是“明确处理规则”尤其是特殊情况和边界条件。数据为空怎么办文件不存在怎么办重复数据怎么处理你不说AI默认按“理想情况”处理你手上真实数据一上准出问题。第三个要素是“明确不做的事情”。不引入额外依赖、不用某些高层API、不能阻塞主进程、不改变原有目录结构这些“反向约束”往往比正向描述更能让AI收敛到你的期望范围。3.3 让AI帮你拆任务而不是替你写代码初学者最容易犯的一个错是让AI一次生成整个项目。一个管理后台、一个商城、一个App这种量级的项目一次提问根本聊不清楚AI给出来的东西一定是一个“看起来完整但什么都没接好”的骨架真正用起来处处断。我的习惯是先让AI帮我拆任务再让它逐个模块写。比如我想做一个“团队周报自动汇总工具”我不会说“给我写一个周报工具”我会先问我想要一个团队周报自动汇总工具。每位成员往一个文件夹里提交Markdown格式的周报文件我需要把它们汇总成一个总报告并统计每个人写的字数。 请先帮我梳理一下这个工具需要拆成哪几个模块、每个模块的核心职责是什么、模块之间怎么衔接给出一个开发顺序建议。AI会给出一份模块清单文件读取模块、内容解析模块、字数统计模块、汇总生成模块。然后我再让它按顺序逐个实现每个模块实现完我跑通验证再进入下一个。这样做的好处是单个模块的上下文足够聚焦AI生成的代码质量明显更高而且每一步都能验证出问题能立刻定位到是哪个模块。3.4 上下文管理的三个技巧用过对话型AI编程工具的人一定经历过“聊着聊着它就忘了前面的要求”的崩溃。这不是AI变笨了而是上下文超限了。我们的任务是学会管理上下文。第一个技巧是“重新声明约束”。每次让它改代码不要只说“把函数改成异步”而是把之前的约束重新带上“继续使用Python输入格式还是上一轮说的日志格式改成异步读取其他不变。”重复声明虽然啰嗦但能有效防止它跑偏。第二个技巧是“做减法”。当上下文越来越长、AI越聊越糊涂的时候果断开一个新对话把核心需求和关键代码粘贴进去重新开始。不要舍不得带病讨论只会让答案质量越来越差。第三个技巧是“用文件作为上下文锚点”。把关键的函数、接口定义单独放一个文件让AI基于这个文件来修改比贴二十段对话记录靠谱得多。你可以直接说“请先读一下src/parser.py这个文件然后我告诉你需要改的地方”。4. 实战复盘用AI做一个访问日志分析看板4.1 项目目标与需求拆解说再多理论不如完整跑一个项目。下面我用一个虚构项目“访问日志分析看板”作为例子走一遍AI编程从拆需求到上线的完整流程。这个项目不复杂用户上传一份访问日志文件系统解析统计数据网页上展示访问量走势、页面排名、浏览器占比等图表。我拿到这个需求后第一件事不是写代码而是拆模块。我让AI先帮我梳理系统结构它给出的拆解结果是日志解析模块、数据统计模块、API接口模块、前端展示模块。然后我进一步细化每个模块的输入输出日志解析模块输入是原始日志文本输出是结构化记录列表 数据统计模块输入是记录列表输出是PV、UV、页面访问Top榜、浏览器分布等指标 API接口模块暴露几个查询接口前端页面调用后渲染图表。这个拆解看起来平平无奇但它决定了后面所有AI交互的质量。因为每个模块足够小我提示词里可以写清楚输入输出AI给的代码就非常聚焦。4.2 第一阶段让AI生成日志解析核心模块日志解析模块是我第一个要做的。我准备了一份样例日志每行格式如下2025-04-10 10:15:22|192.168.1.23|GET|/products/123|200|Mozilla/5.0 2025-04-10 10:15:30|192.168.1.45|GET|/home|200|Mozilla/5.0 2025-04-10 10:16:01|192.168.1.23|POST|/cart/add|302|Mozilla/5.0我给AI的提示词是你是后端开发工程师。请写一个Python函数解析上述格式的日志文本。 字段分隔符是竖线|顺序为时间、IP、方法、路径、状态码、User-Agent。 请完成以下要求 1. 返回一个列表每个元素是字典包含六个字段 2. 某一行字段数量不对时跳过并把行号记录到errors列表中 3. 状态码转为整数转换失败也跳过并记入errors 4. 函数签名是parse_logs(text: str) - dict返回值里包含records和errors两个键AI生成的代码大致是这样的def parse_logs(text: str) - dict: records [] errors [] for idx, line in enumerate(text.splitlines(), start1): line line.strip() if not line: continue parts line.split(|) if len(parts) ! 6: errors.append({line: idx, reason: field_count_mismatch}) continue ts, ip, method, path, status_str, ua parts try: status int(status_str) except ValueError: errors.append({line: idx, reason: invalid_status}) continue records.append({ ts: ts.strip(), ip: ip.strip(), method: method.strip(), path: path.strip(), status: status, ua: ua.strip() }) return {records: records, errors: errors}这段代码中规中矩逻辑清晰。我拿到后没有直接信任它而是自己补了一个空行测试、一个缺失字段测试、一个状态码异常测试全部跑过才进入下一步。这里想提醒一下AI生成的代码第一遍能过说明提示词质量还行但“能过”不等于“没问题”测试和审查不能省。4.3 第二阶段统计接口和前端页面日志解析完成后我让AI继续生成数据统计模块。这次我给了一个更明确的需求统计总PV、总UV、热门页面Top10、每小时访问量、浏览器占比。UV统计我要求按IP去重浏览器类型我要求简单归因到Chrome、Firefox、Safari、Edge、其他五类。AI给了统计函数核心逻辑是from collections import Counter from urllib.parse import urlparse def compute_metrics(records): pv len(records) uv len({r[ip] for r in records}) path_counter Counter(r[path] for r in records) hour_counter Counter(r[ts][11:13] for r in records if len(r[ts]) 13) browser_counter Counter(classify_browser(r[ua]) for r in records) return { pv: pv, uv: uv, top_paths: path_counter.most_common(10), hourly: dict(sorted(hour_counter.items())), browsers: dict(browser_counter) }浏览器归因函数我让它不要引入正则库之外的重型依赖用简单的字符串包含判断就行。这一段生成后我顺手把AI生成的接口层代码接好一个轻量级HTTP服务暴露三个端点一个用于上传日志文本、一个用于获取统计数据、一个用于健康检查。前端部分我用了HTML加一个轻量级图表库页面提供粘贴日志的文本框点按钮后调接口渲染图表。前端提示词我这样写你是前端开发工程师。请写一个单页HTML文件包含以下功能 1. 页面中央是一个多行文本框用户可以粘贴访问日志文本 2. 一个“分析”按钮点击后将文本POST到接口地址 /api/analyze 3. 接口返回JSON包含pv、uv、top_paths、hourly、browsers 4. 请把返回的数据渲染为四块卡片PV/UV总览、热门页面列表、每小时访问量柱状图、浏览器占比 5. 不超过300行样式用简洁的卡片式布局使用一个轻量级图表库来画图AI生成的页面我改动很少主要调整了部分字段名和接口返回结构。这个阶段的整体耗时大约是我以前手工写的四分之一。整个过程AI承担了初稿我做的是设计审核和微调。4.4 第三阶段联调、重构与收尾模块拼起来之后真正的麻烦才开始。我先拿准备的样例日志全流程跑了一遍发现两个问题。第一个问题浏览器分类结果不准确。某并手机浏览器的User-Agent字符串里既包含“Mobile”又包含“Safari”我的归因逻辑把部分手机浏览器错误算进了“Safari”。我调整了判断顺序先识别“Chrome”和“Edg”再识别“Firefox”最后才识别“Safari”并把“Mobile Safari”单独归为“Mobile Browser”。这个调整是我根据AI给的分类代码逻辑自己分析出来的AI看不到你的业务预期只有你知道哪些类别是合理的。第二个问题小时柱状图的横轴顺序混乱因为字典排序后转JSON时变成了字符串排序“10”排在“2”前面。我让AI把小时的键值转成整数排序hourly: dict(sorted(hour_counter.items(), keylambda x: int(x[0])))这个细节如果不修展示窗口上就是一个排列错乱的时间轴观感很差。修复后我又做了一次全量测试包括空日志、超大日志、完全乱格式的日志、重复IP的UV校验确认结果正常才收尾。4.5 整个过程中我和AI的分工复盘这个项目我和AI的分工大致是我负责需求拆解、模块边界定义、输入输出约定、测试用例设计、结果验证和业务修正AI负责代码初稿生成、重复性代码编写、快速原型搭建。我做的事情没有减少但我的时间分配从“写代码”变为了“定方案和审代码”。这里我想强调一个反直觉的经验AI编程写得越多你的代码审查能力反而越重要。以前你写每一行代码都自然知道它的行为现在代码是AI生成的你接手的是别人机器的成品你必须能读懂它、判断它、改造它。我会在每次接AI代码时强制自己先通读一遍标出不懂的地方再逐段验证。这个过程既是对AI的审查也是对自己能力边界的补充。5. 避坑指南这些坑我替你踩过了5.1 提示词太偷懒代码全靠猜最典型的翻车现场是“帮我写个爬虫”“帮我做个管理系统”“帮我写个登录”。这些需求在老手眼里等于没说但AI给起代码来却格外积极它会在自己假设的一个业务场景里写得头头是道。你拿真实业务去套只能一声叹息。解决办法只有一个字细。把你已知的输入格式、输出预期、异常处理、技术约束全部写进去。提示词从一句话扩展到几行返回代码的可用性会从三成提升到八成。我甚至见过有人把提示词当成需求文档写列了十几条约束AI给的代码几乎不用改。虽然麻烦但比来回返工省时间。5.2 盲目接受代码质量问题后知后觉AI生成的代码最大隐患不是“跑不通”而是“跑通了但质量差”。我遇到过几种情况一个貌似等价的函数时间复杂度爆炸数据量一上来就卡死一个多行函数把所有业务逻辑写成一团后续完全没法维护一段网络请求代码没有超时设置外部接口一慢整个程序就挂。应对方式是在接受代码前加一道“审查清单”有没有处理异常输入和边界条件有没有隐藏的超时、阻塞、无限循环风险循环里有没有重复计算、可以提取的公共部分变量命名是否表意清晰函数是否小到容易理解有没有引入不必要的大依赖这道清单不复杂但能拦住绝大多数质量坑。每次生成代码后我至少花两分钟过一遍清单比事后排查Bug省太多时间。5.3 AI一本正经地胡说八道这是大模型的老毛病它为了给出看起来合理的答案会编造不存在的API、不存在的函数参数、不存在的库版本。尤其在它不确定的时候它的表述依然非常自信。新手最容易在这个地方被带偏复制代码后一运行“module not found”或者“attr not found”然后整个人懵了。我的策略是高风险操作先让AI给出方案我再查官方文档验证关键API低风险操作直接跑由编辑器报错来试错。另外遇到它给出的陌生库或版本号我会追问一句“这个API在哪个版本里可用请补充版本限制”让它自己把不确定性暴露出来。5.4 环境与依赖的隐性问题AI生成代码大概率会在和你当前环境不一致的假设下运行。它可能默认你已经安装了某个库默认你的Python版本支持某些新语法默认你的系统路径包含某些工具。这些隐性假设在它生成的代码里不会体现只会在你运行时冒出来。我处理这类问题有两个固定动作。第一每接一段代码先明确声明运行环境“Python版本是3.9操作系统是Windows不能安装需要编译的依赖包”。第二让AI给你“从零跑起来”的步骤说明并要求它写清依赖安装命令。绝大多数时候这两招能把环境不兼容的坑提前排掉。5.5 常见问题速查表现象主要原因排查思路代码运行报ModuleNotFoundError依赖声明缺失查看代码import了哪些包手动安装或在提示词里要求AI列清依赖接口返回数据正确但页面不渲染前后端字段名不一致对比接口JSON字段和前端取值字段统一大小写与命名AI生成的代码逻辑自相矛盾上下文被覆盖新开对话重新粘贴完整需求和关键代码大数据量下性能极差算法复杂度考虑不足检查是否有循环嵌套、全量复制要求AI改用合适的数据结构中文注释或中文文本乱码文件编码问题统一使用UTF-8并在读写文件时显式指定encoding同样的需求每次生成结果不同大模型随机性增加约束条件让生成结果更收敛或固定出题模板6. 建立自己的AI编程工作流6.1 单人效率工作流用顺了之后我给自己定了一套固定的效率流程。第一步写需求的卡片式描述目标、输入、输出、约束、示例。第二步把卡片描述变成第一版提示词交给AI生成骨架代码。第三步本地跑通边跑边把报错、运行结果回喂给AI形成一轮轮“运行—报错—修改”循环。第四步代码稳定后做一轮人工重构把命名改清晰、把大函数拆小、把边界条件补充完整。第五步补上最小测试集。这个流程和传统开发的本质区别在于我把“编码”阶段大量外包给了AI而把“审查”和“重构”变成了我的核心工作。看似每一步都要做其实速度比纯手工快一倍以上。尤其是第四步的“重构”很多人忽略它导致AI写出来的代码状态越来越乱。我自己的经验是每次AI交付代码后先花十分之一的时间做一次结构整理会让后续所有迭代顺畅很多。6.2 团队协作时的几个约定团队里如果大家都在用AI编程有一些规范要提前定好否则代码库会失控。第一AI生成的代码必须经过同行评审不允许直接合入主分支。这不是不信任AI而是保证至少有一个“人”对代码行为负责。第二项目里统一提示词模板里的约束清单比如缩进风格、命名规范、禁用依赖列表这样每个人让AI生成的代码风格差异才不会太大。第三禁止让AI碰敏感的密钥、生产环境配置、用户隐私数据即使它只是“看一眼”也不行。我还见过团队把提示词模板维护在共享文档里新成员入职时直接抄模板生成代码的质量起点就很高。这个办法很笨但效果出奇好。6.3 从编程到全栈AI编程能走多远很多人会问AI编程到底能覆盖到什么程度以我的经验它已经不仅能写代码还能写测试、写SQL查询、写部署脚本、写容器配置、写文档注释、写前端页面。当你能熟练描述需求它可以帮你从一个想法直接走到“能跑起来的原型”甚至“能上线的简单系统”。但它目前很难做好的是需要深度业务判断的架构设计、需要跨团队沟通的复杂依赖协调、需要大量真实用户反馈的产品迭代方向判断。这些事AI能给建议但最终决策还是得人来做。所以“AI编程能走多远”这个问题的答案取决于你的判断力和业务理解能走多远。7. 个人体感最深的三件事说了这么多方法和经验最后分享几件我在实际使用AI编程过程中感触最深的小事。第一件事是我再也回不去死记硬背API细节的状态了。以前写前端调一个冷门接口我要翻文档、试参数、查示例现在这些事我直接交给AI省下来的时间用来读业务代码、想数据模型。但代价是一旦AI抽风给了一个错误的API用法我自己的“知识兜底”就很重要。所以我不会完全放弃基本功只是改变了我记忆知识的侧重点从“背细节”变成了“记体系和思路”。第二件事是代码审查变成了我的日常主战场。以前我审同事代码重点看逻辑、看风格现在审AI生成的代码还要额外看它有没有引入我根本没预期过的东西。有一次它在一个简单的脚本里偷偷用了某个我在生产环境没安装过的库如果我没认真看依赖上线就会炸。所以AI编程让我养成了一个近乎强迫的习惯每次接AI代码先看它import了什么、调用了什么外部命令、访问了什么网络地址。第三件事是AI编程最大的杠杆作用不是让你写得更快而是让你敢想更大的项目。以前我做一个工具脚本要抠细节抠很久所以习惯性避开大一点的工程现在至少原型阶段的成本降了一个量级我有更多底气去接“不太熟悉”的任务。尝试一个陌生领域的小项目从零到跑通也许只需一个下午这个体验会让人的学习路径变得前所未有的灵活。最后再分享一个小技巧请永远保留一份“人肉写的代码”。遇到AI持续跑偏、怎么改都不对的时候先用手写把核心逻辑搭出来哪怕很丑、很朴素再让AI去美化、优化、扩展这样它就有了一个具体参照物不会再天马行空。这个小技巧救过我很多次希望对你也能有帮助。
阅读完成 · 觉得有帮助？
