据了解，“AI 软件开发实战教程”系列第 1 篇：介绍这套教程为什么存在、会怎样推进，以及如何判断 AI 完成的工作是否真的可以进入下一步。 科技新闻。
项目首页应该直接告诉后来者：
下一篇是《教程（二）：从微信群消息中找到真正要解决的问题》，将进入第一次真实产品讨论。
AI背景与起因
仓库：Dev-Wiki/dev-harness 地址：https://github.com/Dev-Wiki/dev-harness
想法可以模糊，开始编码前的产品边界不能模糊。
因此，这套教程真正想建立的不是一条更长的提示词，而是一套可以检查的开发过程：
AI事件经过
产品讨论不从页面数量和技术选型开始，而是追问：
例如，邻行计划借助第三方服务向微信发送提醒，还需要验证：
“有条件继续”称可以准备不依赖缺口的工作，但不能把尚未验证的部分写成确定承诺。
AI各方回应
当生成速度越来越快，我们怎样知道自己正在更快地接近正确结果，而不是更快地制造返工？
这套教程不是固定不变的剧本。每一篇文章对应一个真实节点，只有前一个节点留下足够证据，后一个节点才会开始。
整个开发过程会产生大量真实材料：
AI影响分析
例如，“用户需要智能推荐”“用户愿意注册”“用户愿意填写联系方式”，都不能只靠开发者和 AI 互相认同。
直接生成完整产品通常会遇到四类问题。
长期有效的知识需要进入仓库：
本系列会根据实际阶段使用其中的产品讨论、产品评审、工程评审、真实浏览器检查、代码审查、上线检查和复盘能力。工具是否使用，以每篇文章的真实记录为准。
仓库：garrytan/gstack 地址：https://github.com/garrytan/gstack
当前已经完成：
项目还没有真实用户反馈，就开始规划第一个版本、第二个版本甚至正式版本。这样的路线图看起来清楚，实际往往只是把当前想象分配到不同时间。
产品规划需要回答：
产品、架构和关键页面流程明确以后，才适合生成开发任务。
已经过时但仍有追溯价值的材料，可以先提交到版本历史，再从工作区删除。这样既不会让后续 AI 误读，又不会丢失项目怎样一步步调整的证据。
写下这篇文章时，“邻行”还没有开始业务代码开发。
一些产品能力依赖第三方服务、特定浏览器或真实设备，不能只阅读说明后就认为可行。
仓库：nextlevelbuilder/ui-ux-pro-max-skill 地址：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
产品讨论指出的高风险假设，需要通过访谈、观察或小规模试验验证。
它可能被理解成信息板，也可能被扩张成包含支付、派单、地图、聊天、评价和订单的完整拼车平台。两种理解都能生成很多代码，但它们解决的不是同一个问题。
本系列计划使用 dev-harness 的计划能力，把稳定的产品和架构材料转换成看板。看板是执行工具，不是替代产品讨论的工具。
AI 工具通常擅长起步一个任务，却不一定会主动处理任务之间的交接。
当这条链路真正跑通以后，AI 才不只是一个速度很快的代码生成器，而是进入了一套能够持续交付软件、也能被后来者继续维护的工作方式。
AI 已经很会写代码了。
视频是可选产物，不是项目完成门禁。
这句话足够让 AI 开始写代码，却不足以让我们判断应该写什么。
只保存在聊天里的结论有三个问题：难以搜索、难以审查、难以让新会话继承。
例如，产品讨论已经完成，但它所属的产品验证阶段可能仍然缺少用户访谈。若只在文档上写“完成”，下一个 AI 会话就可能直接进入架构和开发。
更严重的是，页面隐藏了某个字段，不代表接口和页面源代码没有泄露它。
上线以后还要观察页面错误、响应时间、后台任务和第三方服务失败。发布完成不是停止验证，而是验证环境从本地变成了真实生产环境。
访谈不是向用户介绍方案，也不是问“你觉得这个产品好不好”。更有价值的问题是：
最初的想法很简单：
这确实降低了开发门槛，却也带来了一个新的问题：
当前尚未完成：
但真实项目不一定随时具备访谈条件。如果当前确实无法接触目标用户，不能为了让流程看起来完整而编造访谈。更诚实的做法是把“没有完成用户验证”写入检查点，继续推进不依赖该证据的工作，并在产品规划中把相关结论标成假设。
AI 可能先生成所有数据库模型，再生成所有接口，最后补页面。后果是每一层都“完成了一部分”，用户却走不通一条完整流程。
把这些缺口公开写出来，是为了让教程记录真实过程，而不是为了显得流程完整。下一步会在保留用户接受度假设的前提下形成正式产品规划草案。
这些材料首先整理成图文教程。图文足够清楚时，可以直接发布，不必为了“完整”强行制作视频。
一个纵向任务应尽量同时包含页面、服务端规则、数据保存和验证，避免先生成所有模型，再生成所有页面，最后才发现流程无法连起来。
你可以告诉它想做一个什么产品，它很快就能生成页面、接口、数据库，甚至顺手补上一份看起来很完整的产品规划。
AI 会话会结束，新的会话不应该依赖旧聊天记录才能继续开发。
访谈记录要区分用户原话、观察和解释。否则 AI 仍然可能把开发者的理解加工成用户结论。
自动检查适合验证确定规则，例如：
我准备通过一个真实项目，完整记录从想法到上线的过程。
两者不能互相替代。
因此，本系列坚持把长期有效的信息放入仓库，并且只保留当前有效入口。
所以，本系列不把“生成了多少代码”当作进度，而把“形成了多少经过验证的闭环”当作进度。
当后来发现核心需求判断错了，所有版本都会一起变化。
自动测试只能证明被覆盖的规则没有失败。它不能自动证明手机页面好用、复制功能在微信内置浏览器中有效、部署后数据不会丢失，也不能证明生产自然环境没有使用错误配置。
页面设计也不能只追求“看起来像一个现代应用”。需要围绕真实任务验证：
版本规划的主要作用不是预测遥远未来，而是给当前版本一个停止位置。
原始材料是后续判断的起点。如果没有它，产品文档很容易变成自洽但无法核实的故事。
开发者仍然需要负责：
本系列计划使用它维护项目上下文、统一构建与检查命令、生成开发计划和任务看板，并规范情况修复与版本管理过程。
真实浏览器验收则检查另一类问题：
后续落地：本文写作后，项目把分支策略、提交格式、版本选择、发布门禁和 tag 要求 固化到项目的 Git 与发布工作流，并用变更日志区分待发布变更与正式版本。 历史文章继续保存当时过程， 当前协作和发布操作以这两份文件为准。
产品讨论的产物仍然不是可以直接编码的命令，它更像一份经过追问的设计和待验证清单。
AI 适合：
这套流程不是让开发者逐行指挥 AI，也不是把所有决定交给工具。
这种小范围、可复现的技术试验应在锁定工程方案前完成。失败并不可怕，危险的是没有试验就把候选方案写成已确认依赖。
每个纵向任务按照下面的顺序完成：
先保存真实消息、用户行为和当前解决方式，不要急着把它们改写成正式需求。
这是一种证据受限的继续，不表示访谈没有价值。读者在开发自己的产品时，如果能够接触目标用户，仍应优先完成真实访谈或行为观察。
开发计划不能只有“完成登录”“完成搜索”这样的标题。每个任务至少需要：
AI 可以加快判断过程，但不能凭空制造用户证据，也不能替产品承担责任。
当真实反馈改变了核心判断，应该修改版本规划，而不是为了维护旧文档继续实现错误范围。
产品范围稳定以后，再决定怎样实现。
AI 降低了写代码的成本，却没有自动消除错误需求、权限漏洞、失败路径、发布风险和知识丢失。
微信群已经聚集了用户，也承担了最终沟通。但供需双方经常不会同时出现，较早的信息很快被新消息刷走。用户只能重复发送、向上翻找，或者不断询问“刚才那辆车还有吗”。
本项目使用了 gstack 中的 office-hours 产品讨论技能。它的价值不是代替开发者拍板，而是不断暴露证据不足和前后矛盾。
需要区分：
理想情况下，正式产品规划应同时吸收产品讨论和关键用户证据。如果访谈当前无法执行，也可以基于已有行为证据形成草案，但必须明确哪些结论没有获得目标用户确认，并避免使用“用户已经接受”“已经验证”等表述。
页面体验设计工具可以提供配色、字体、间距和交互建议，但产品事实必须决定设计方向。
这个系列不会展示“一句话生成完整应用”，而是尝试建立一条普通开发者也能重复使用的路线：
图文教程是这条路线的主要记录形式。视频可以在项目交付以后再生成，也可以完全不做。内容形式不能代替软件本身的完成证据。
工程架构至少需要说明：
这个项目叫“邻行”，来自小区顺风车微信群里的真实问题。
群里有车的人发布“车找人”，准备坐车的人发布“人找车”。消息通常包含时间和路线，例如：
做一个更容易发布和查找同路信息的工具。
一个应用能够运行，不代表它解决了真实问题；测试显示通过，不代表用户真的能在手机上完成任务；AI 说“已经完成”，也不代表权限、隐私、失败处理和发布过程都有证据。
如果以后需要视频，可以按章节把已完成的文档和证据导入 Google NotebookLM 等工具，辅助生成讲解结构、旁白和解释画面。关键操作、测试失败、浏览器验收和发布成果仍应使用真实记录，不能把计划中的功能制作成仿佛已经完成的演示。
因此，每个重要节点终结后，都要单独回答：
它会具体展示：
门禁结论只有三种：
因此，本系列的第一条规则是：
一个真正可继承的项目，应该允许新的 AI 会话只读取仓库，就能说明当前阶段、下一步和不能做什么。
开发阶段采用测试驱动方式，但重点不是机械地追求测试数量。
开发者觉得用户会喜欢某个功能，AI 就把它写进规划；规划写得越正式，这个未经验证的想法越容易被当成事实。
准备发布时，需要重新检查：
产品规划和关键用户流程稳定以后，本系列计划使用它辅助建立移动端页面的色彩、字体、间距、表单、状态反馈、响应式和无障碍设计基线，引发了热烈讨论。
