背景描述
当下推理模型的能力进一步增强，gemini-2.5pro, kimi-k2在代码编辑层面都非常强。因此在尝试一种新的写代码方式，那就是人机协同。
人机协同：人提供关键的信息以及这些信息是需要模型能够看的懂，模型根据提供的信息，输出对应的代码。在模型输出代码的过程，人只需要在关键时刻进行代码review，剩余时间，抽烟、喝酒、烫头样样来。
下面我以我当下的体验，进行记录与反馈。
AI能看懂的材料
在让AI帮你干活之前的第一步，就是需要先给模型灌输对应的上下文 ，没有清晰的上下文，模型就像瞎子摸象，出现幻觉。反过来被你说一句：不过如此，还不如我写。
当下，不管是屎山代码或是新项目，总归是服务于业务，服务于业务，那就有非常清晰的流程图（虽然可能充斥着if else 逻辑，但总归是有起点与终点），后端对应的表设计、产品的PRD，前后端技术栈、前后端项目目录，这些都是模型需要的上下文信息，而且越具体以及精确，越能激发模型的潜能。
那以上信息我们该以什么方式喂给模型呢？在讨论这个问题之前，我们首先需要思考的就是模型能看得懂什么，从而可以反推出以什么方式喂给模型作为上下文。总不可能我丢给模型一篇文档，里面有流程图截图、有零碎的上下文信息，然后告诉模型，给我干，干不出来我就PUA你垃圾，不过如此。因此我们需要看模型能够看懂什么。
不管如何，第一步都是需要先梳理出流程图、交互图、业务信息、项目信息、技术栈信息等。再考虑下一步。关于以上信息如何高效的喂给模型，我从我的实际体验出发，给出对应的建议。
流程图 : 在使用AI的过程中，当我描述一个业务流程时，模型输出的流程图、时序图等，均是以mermaid 进行输出，原因也很简单，从文字描述 + 对应的规范即可生成可视化的流程图，因此在流程图层面推荐使用mermaid进行提供，并且最好提供流程图（告诉业务逻辑）以及时序图（告诉技术层面如何实现）。
PRD: 产品层面可能会有很多PRD，但是细想，PRD无非是新的业务链路或是对之前已有链路的逻辑改造。因此我们应该维护的是大而全的PRD,在PRD中抽象出对应的业务功能，针对每次改动，在下发增加change log，最后在对最新的业务功能进行细分描述，并可与上文所说的流程图做关联。
DB表: DB表等信息较为简单，只需要维护好对应的md文档，以及维护好更新历史。比如：字段的增删是因为什么原因，可以关联PRD中的具体某个change log。
技术框架&目录: 不管前后端，都会有自己的技术栈，例如：前端的是react/vue等，后端java/c++等，精准的告诉模型，方便模型做向量匹配，相当于prompt中的 Role一样，目录能够加快模型快速去查找或定位对应的功能，在我的项目中，当下喂给模型的如下：
text
前端技术栈
跨端框架：Taro 3
UI组件库：Taro UI
状态管理：zustand
网络请求：axios
编码语言：ts
文件目录
src
├── components # 全局组件
├── pages # 页面
├── services # 服务层
├── utils # 工具函数
├── xxx # 其他文件
### 页面目录
src/pages
├── index # 模板页
├── xxx # 其他文件
### 组件目录
src/components
├── common # 全局组件
├── index # 首页组件
├── template # 模板页组件
后端技术栈
node框架： Koa
数据库：MySQL
数据缓存：Redis
数据库操作SDK： sequelize
编码语言：TS
鉴权：JWT
文件目录
src
├── controllers # 控制器
├── middleware # 中间件
├── config # 配置
├── routes # 路由
├── services # 服务层
├── utils # 工具函数
├── app.js # 应用入口
├── db.js # 数据库连接
├── index.js # 应用初始化Prompt
在有了上述信息后，我们在后续的开发过程中，就可以引用对应的文档或者流程图，以及告诉模型我们本次技术层面需要实现的功能，以及当下的流程图以及前后端如何交互的泳道图，帮我们实现对应的代码片段。以trae为例：方便模型能够快速的理解业务需求和技术要改造的点（如能精确到具体文档，则更好），
text
该项目是一个前后端分离项目，其中client是前端，server是后端。
对应的细分目录在 README.md 中，
对应的该流程图以及时序图在 sequenceDiagram.md 中
对应的PRD以及change log在prd.md中，其中每个业务流程中，包含之前的业务逻辑以及本次的 change log
对应的DB设计在 db.md 中，请参照以上，实现server端代码
要求的功能有：
1. 任何请求，都需要经过jwt校验，如果未校验通过，则返回401状态码。校验通过则进入后续流程，后续流程中返回的数据结构必须有statusCode以及statusMsg,statusCode为0，表示业务正确请求，非0表示业务处理错误
1. 用户登录接口，执行xxx逻辑。
2. 查询用户接口，如果没有查询到，返回非0状态码，如果查询到，则返回用户信息。
3.提供xx创建接口，需要校验xx，yy, zz，xx演示地址URL是否存在，如不存在，返回非0状态码。
4.xxxxxxxx
根据以上信息，帮我生成对应的代码片段以及解释这样写的原因。效果展示
写在最后
实践是检验真理的唯一办法，对待新事物，要拥抱，而非抵触或担忧。