人机协同交付：非程序员用AI实战交付18.6万行企业级代码

1. 这不是“AI写代码”，而是用AI重构交付链路的实战复盘

53岁，没写过一行Python，没碰过Git，连npm install都得查三次命令——这是我启动这个项目时的真实状态。标题里那句“交付了18.6万行代码”，不是炫技，是实打实的工程日志统计：微信小程序前端源码（含WXML/WXSS/JS/JSON）共42,817行，云开发后端（云函数+数据库规则+云调用配置）31,592行，SCM系统Web管理后台（Vue3+Element Plus+Axios封装）68,304行，再加上自动化部署脚本、CI/CD流水线配置、API文档Markdown、测试用例与用户操作手册，合计186,341行。这些代码全部由我本人在2023年9月—2024年3月间，通过AI辅助完成，并已稳定上线服务3家制造企业客户。

关键词里没填，但核心就四个字：人机协同交付。不是让AI当替身，而是把我这个非程序员的业务理解力、流程设计直觉、用户反馈敏感度，和AI的语法生成力、模式复现力、文档检索力、错误自检力，焊死在一条工作流里。比如“微信小程序顶部导航栏高度”这个热搜词，背后不是CSS像素问题，而是我反复对比12家竞品小程序后，在提示词里写进：“按iOS安全区+安卓状态栏双适配，顶部留白必须≥44px且不遮挡胶囊按钮，导出WXSS时禁用rpx转px”——AI照做，一次通过真机测试。再比如“微信小程序登录获取手机号”，我根本不懂button open-type="getPhoneNumber"的scope值校验逻辑，但我知道用户点击后必须“无跳转、无弹窗、3秒内返回手机号或明确失败原因”，于是我把这个业务约束喂给AI，它自动补全了云函数校验签名、解密、绑定unionId的完整链路，还顺手写了异常兜底的toast提示文案。

这项目不是教你怎么调API，而是告诉你：一个懂业务、懂用户、懂交付节奏的人，如何把AI变成自己手里的“第二大脑”。它不替代思考，只放大判断；不省略决策，只压缩执行。下面所有内容，都是我在真实交付中撕开的切口、踩过的坑、磨出的刀锋。

2. 从“不会写代码”到“定义代码”的思维跃迁

很多人卡在第一步：面对AI工具，第一反应是“让它帮我写个登录页”。结果生成一堆无法运行的碎片，陷入调试地狱。我的破局点很朴素——先放弃“写代码”，专注“说清楚要什么”。这不是偷懒，而是把程序员最耗神的“需求翻译”环节，提前固化为可迭代的提示工程。

2.1 用“业务语言”构建三层提示结构

我给自己立了铁律：所有AI交互必须包含三个不可删减层。以SCM系统中的“采购订单审批流”为例：

• 第一层：角色与场景锚定
  “你是一名有15年制造业ERP实施经验的高级顾问，正在为华东一家年营收2.3亿的五金配件厂设计采购审批流程。当前痛点：采购员提交订单后，需经部门主管→财务初审→采购总监→总经理四级纸质签批，平均耗时5.7天，超期订单占32%。”

• 第二层：行为约束与边界条件
  “输出必须满足：① 审批节点支持动态增减（非硬编码）；② 每个节点可配置‘自动通过阈值’（如金额＜5万元免财务初审）；③ 审批驳回时强制填写30字内原因；④ 全流程留痕，含操作人/IP/时间戳；⑤ 微信小程序端需支持离线暂存草稿。”

• 第三层：交付物格式指令
  “输出格式：① Mermaid流程图（仅文字描述，不生成图像）；② 小程序页面WXML结构（含data-bind字段名）；③ 云函数名称与入参JSON Schema；④ 数据库collection设计表（含字段名、类型、索引、权限规则）；⑤ 测试用例表格（含正常流/驳回流/超时流/网络中断流）。”

提示：这三层结构不是玄学。第一层让AI进入领域语境，避免通用化方案；第二层用具体数字和百分比建立可信边界，防止AI自由发挥；第三层强制结构化输出，直接对接后续开发环节。我试过删掉任何一层，生成质量断崖式下跌。

2.2 把“不会写代码”转化为优势：反向校验机制

传统程序员容易陷入技术细节，而我的“零基础”反而成了质量防火墙。我会刻意用外行视角追问AI生成物：

• 看到云函数返回{code:0,data:{order_id:"PO20240301001"}}，立刻问：“如果用户手机没网，这个order_id怎么同步到本地缓存？小程序离线时能查到刚提交的单号吗？”
• 看到数据库字段approval_status: string，马上质疑：“为什么不用enum？如果后期增加‘加急审批’状态，现有所有查询逻辑都要改，有没有更健壮的设计？”

这种追问倒逼AI给出带容错设计的方案。最终SCM系统的审批状态字段，AI给出了三套方案让我选：① 字符串枚举（简单但扩展差）；② 数字编码+映射表（性能好但维护难）；③ 引用独立status_config集合（最重但最灵活）。我选了第三种——因为五金厂老板亲口说过：“我们明年要上ISO9001，所有流程变更必须留审计痕迹。”这个业务洞察，是任何代码生成器都无法预设的。

2.3 拒绝“AI幻觉”，建立可验证的交付标准

最危险的不是AI写错代码，而是它写得“太像对的”。我制定了三条硬性验证红线：

1. 真机可测：所有小程序页面生成后，必须用真机扫码测试，重点验证：顶部导航栏是否遮挡胶囊按钮、下拉刷新是否触发、输入框聚焦时键盘是否顶起页面；
2. 数据可溯：所有云函数调用，必须在云开发控制台能看到完整的请求/响应日志，且响应时间＜800ms（微信官方建议阈值）；
3. 权限可控：数据库读写规则必须通过“模拟器测试”验证，例如：采购员账号登录后，只能看到自己提交的订单，绝不能通过修改URL参数越权访问他人数据。

有一次AI生成的登录接口，本地调试全绿，但真机测试时发现iOS微信会拦截wx.login()的code，导致静默失败。我立刻把这个问题作为新提示词喂给AI：“修复微信iOS端wx.login()在部分机型静默失败的问题，要求兼容iOS15+微信8.0.42以上版本，提供降级方案（如引导用户手动点击授权按钮）”。它不仅修正了代码，还附上了微信官方文档链接和兼容性测试矩阵表。

3. 微信小程序：用“组件化提示”替代“页面级生成”

很多新手以为AI能一键生成整个小程序，结果得到一堆无法嵌套的孤立文件。我的策略是：把小程序拆解为12个原子级可验证组件，每个组件用独立提示词驱动，再用主框架粘合。这源于我对微信小程序架构的深度观察——它的核心不是“页面”，而是“组件复用”。

3.1 原子组件清单：从高频痛点反向定义

我梳理了制造企业SCM场景中最高频的12个交互单元，每个都对应一个可独立生成、测试、复用的组件：

注意：这份清单不是凭空列的。我花了两周时间蹲点三家工厂仓库，记录采购员每分钟的操作动作、报错频率、口头抱怨。比如C02“物料扫码录入”，最初AI生成的版本只支持扫描，但实际中采购员常需手动输入条码——于是我追加提示：“增加手动输入条码框，输入后自动触发匹配逻辑，且输入框需支持中文模糊搜索（如输入‘螺栓M8’匹配‘M8×30六角头螺栓’）”。

3.2 组件生成的“三步验证法”

每个组件生成后，我执行标准化验证流程：

第一步：结构校验
用VS Code打开生成的WXML，检查是否包含<template name="xxx">标签，data属性是否全部声明在Page.data中，事件绑定是否符合bind:tap="handleXxx"规范。曾发现AI生成的组件把bind:input写成bind:change，导致实时搜索失效——这个错误肉眼3秒可判，但新手常忽略。

第二步：真机压测
在iPhone 12和华为Mate 40上同时扫码10次，记录首次渲染时间、连续扫码卡顿率、内存占用峰值。C04“PDF生成”组件初版在华为机上生成一张A4 PDF需4.2秒，我要求AI优化：“将wxml2canvas替换为jsPDF+html2canvas组合，优先保证生成速度，允许PDF字体轻微失真”。优化后降至1.3秒，且失真在可接受范围。

第三步：业务闭环测试
以C01“多级审批选择器”为例，不只测UI，更要测业务流：选择“采购总监”节点后，系统是否自动跳过财务初审？当订单金额改为4.9万元时，是否真的不触发财务节点？我用Postman模拟云函数调用，传入不同金额参数，验证返回的审批路径是否符合预期。

3.3 主框架粘合：用“骨架先行”规避集成灾难

所有组件生成完毕后，最关键的一步是搭建主框架。我坚持“骨架先行”原则——先用AI生成最简化的app.js/app.json，只包含tabBar和基础路由，再逐个注入组件。

生成app.json的提示词示例：
“生成微信小程序app.json配置，要求：① tabbar包含‘首页’‘采购’‘库存’‘我的’4个页面；② ‘采购’页面使用自定义tabBar（因需显示未读审批数）；③ 所有页面启用pullDownRefresh；④ 禁用navigationBar，顶部导航由自定义组件C01实现；⑤ 分包加载：‘库存’页面单独分包，大小＜2MB。”

这个看似简单的配置，解决了两个致命问题：

• 自定义tabBar的未读数显示：AI生成的代码自动在tabBar图标旁添加badge，且通过wx.setTabBarBadgeAPI动态更新；
• 分包加载的体积控制：当“库存”页面引入ECharts图表库后，AI主动将node_modules中非必要模块移至主包，确保分包体积合规。

如果没有这个骨架，等所有组件写完再整合，大概率出现路由冲突、样式污染、分包超限等问题——这是无数团队踩过的坑。

4. 企业级SCM：用“领域知识注入”对抗AI的通用化陷阱

SCM系统不是功能堆砌，而是业务规则的数字化表达。AI天生倾向通用方案，而制造业SCM的魔鬼在细节里：比如“安全库存”计算，通用方案是平均日消耗量×采购周期，但五金厂的实际规则是（上月消耗量×0.7 + 上上月消耗量×0.3）×（采购周期+3天缓冲）。这类业务专精逻辑，必须靠人工注入。

4.1 构建制造业SCM知识图谱

我整理了五金制造企业的17条核心业务规则，每条都转化为AI可理解的提示词模板：

• 规则1：采购周期动态计算
  “采购周期=供应商A类（交期≤7天）→3天；B类（7＜交期≤15天）→7天；C类（交期＞15天）→15天。供应商分类依据：近6个月准时交货率≥95%为A类，85%-94%为B类，＜85%为C类。”

• 规则2：物料ABC分类法
  “A类物料（年采购额前20%）：库存预警阈值=安全库存×1.5，每日巡检；B类（中间60%）：阈值=安全库存×1.2，每周巡检；C类（末20%）：阈值=安全库存，每月巡检。”

• 规则3：供应商绩效评分
  “总分100分=交货准时率（40分）+质量合格率（30分）+服务响应（20分）+价格竞争力（10分）。其中交货准时率=（准时交货次数/总交货次数）×40，迟到≤24小时扣5分，＞24小时扣10分。”

关键技巧：我把这些规则写成Excel表格，用AI插件（如ChatExcel）直接解析，再让AI根据表格生成数据库字段和计算逻辑。例如上传“供应商分类规则表”，AI自动创建supplier_category字段，并生成云函数calculateSupplierCategory()，连单元测试用例都一并产出。

4.2 云开发后端：用“权限即代码”实现企业级安全

企业级系统最怕权限失控。我要求AI生成的云函数，必须内置RBAC（基于角色的访问控制）逻辑，且权限规则写死在代码里，而非依赖云开发控制台配置——因为后者无法版本化、不可审计。

以“删除采购订单”功能为例，AI生成的云函数包含三重校验：

// 云函数 deleteOrder.js exports.main = async (event, context) => { const { OPENID, APPID } = cloud.getWXContext() const { orderId } = event // 第一重：身份校验（必须是采购员或管理员） const userInfo = await db.collection('users').where({ openid: OPENID }).field({ role: true }).get() if (!['purchaser', 'admin'].includes(userInfo.data[0].role)) { return { code: 403, msg: '无删除权限' } } // 第二重：业务校验（仅可删自己提交且未审批的单） const order = await db.collection('orders').doc(orderId).get() if (order.data[0].creator_openid !== OPENID || order.data[0].status !== 'draft') { return { code: 400, msg: '仅可删除本人草稿状态订单' } } // 第三重：审计留痕（记录谁删了什么） await db.collection('audit_logs').add({ data: { action: 'delete_order', target_id: orderId, operator_openid: OPENID, timestamp: new Date() } }) return await db.collection('orders').doc(orderId).remove() }

提示：这段代码的关键不在技术，而在业务逻辑的穷举。我特意要求AI加入“第三重审计留痕”，因为五金厂老板强调：“ISO审核时，必须证明所有数据变更可追溯。”这个需求，是任何通用云开发教程都不会提的。

4.3 数据可视化：用“业务指标驱动”替代“图表堆砌”

企业客户不要酷炫大屏，只要一眼看懂关键指标。我定义了SCM系统的5个黄金指标，每个指标对应一个可解释的图表：

生成这些图表时，我给AI的指令非常具体：“用ECharts 5.4.3，柱状图Y轴必须显示百分比，tooltip中显示‘供应商A：92.3%（较上月+1.2%）’，点击柱子跳转至该供应商详情页”。AI不仅生成代码，还自动处理了数据格式转换（如把数据库返回的[{name:'A',value:92.3}]转为ECharts需要的[{name:'A',value:92.3,percent:'92.3%'}]）。

5. 交付物管理：用“版本化提示词”终结AI输出的随机性

最大的交付风险不是代码bug，而是AI输出不可复现。今天生成的登录页，明天可能变成另一个版本。我的解决方案是：把提示词本身当作代码来管理，建立版本控制系统。

5.1 提示词版本化：git管理的不只是代码

我在GitHub新建了scm-prompt-repo仓库，目录结构如下：

/scm-prompt-repo ├── v1.0/ │ ├── login-flow.md # 登录流程提示词（含微信授权+手机号获取） │ ├── order-approval.md # 订单审批流提示词 │ └── database-schema.md # 数据库设计提示词 ├── v1.1/ │ ├── login-flow.md # 新增“手机号一键登录”分支逻辑 │ └── audit-log.md # 审计日志增强提示词 └── prompt-template.md # 提示词编写规范（含三层结构示例）

每次需求变更，我先更新提示词文件，再用新版本生成代码。例如v1.0的登录提示词只支持微信授权，v1.1新增了“手机号一键登录”选项。当我需要回溯v1.0的登录页代码时，只需checkout对应commit，重新运行AI即可获得完全一致的输出。

实操心得：我给每个提示词文件头部添加元信息，例如：

--- version: v1.1 updated: 2024-02-18 author: ZhangSan impact: 影响login-flow.md, order-approval.md（因审批流需关联用户手机号） ---

5.2 输出物标准化：用“交付物清单”锁定AI的生成范围

为避免AI自由发挥，我制定了《SCM交付物清单V2.3》，明确每个模块必须产出的文件：

当AI生成index.js时，我强制要求它在文件末尾添加注释：
// Generated by prompt v1.1 on 2024-02-18. See scm-prompt-repo/v1.1/login-flow.md

这样，任何接手的人都能瞬间定位到源头提示词，无需猜测“这段代码是怎么来的”。

5.3 真机交付检查表：把“上线”变成可执行动作

最后一步，是把抽象的“上线”拆解为27项可勾选动作。这张表我打印出来贴在显示器边框，每完成一项就打钩：

1. [ ] 小程序管理后台已配置合法域名（https://xxx.cloud.com）
2. [ ] 云开发环境ID已填入project.config.json
3. [ ] 所有云函数已部署，且控制台显示“运行成功”
4. [ ] 数据库集合已创建，权限规则已保存并测试通过
5. [ ]app.json中"usingComponents"已注册所有自定义组件
6. [ ]project.config.json中"miniprogramRoot"指向正确路径
7. [ ] 真机扫码测试：首页加载时间＜1.5秒（iPhone 12）
8. [ ] 真机扫码测试：扫码录入物料后，3秒内显示匹配结果
9. [ ] 真机扫码测试：提交采购订单后，云开发控制台可见新记录
10. [ ] 真机扫码测试：切换账号登录，数据隔离正常
    ...
11. [ ] 向客户发送《SCM系统操作速查手册》PDF（含3个高频问题解答）

关键细节：第7项“首页加载时间＜1.5秒”不是拍脑袋定的。我用Lighthouse在真机上跑了10次测试，取P90值（90%的测试结果低于此值）作为标准。第27项的手册，也是用AI生成的——我把客户微信聊天记录喂给AI：“把这12条用户提问，整理成带截图的操作指南，每条不超过80字”。

6. 我的工具链：不追求最新，只选最稳的组合

工具不决定成败，但选错会拖垮节奏。我用的不是“最好”的工具，而是“最不容易翻车”的组合。所有工具都经过3轮真机压力测试，淘汰了7个看似炫酷但真机崩溃的插件。

6.1 核心工具选型逻辑：稳定性＞功能＞颜值

实测对比：用Tabnine生成的WXML，有37%概率把wx:for写成v-for（Vue语法），而Copilot从未犯此错误。这不是AI强弱问题，而是训练数据侧重点不同——Copilot吃透了微信官方文档和社区代码。

6.2 真机调试三板斧：绕过模拟器的虚假繁荣

模拟器永远跑不出真机问题。我总结出三招必杀技：

第一招：用wx.getSystemInfoSync()锁死环境变量
在app.js中写死设备判断逻辑：

const systemInfo = wx.getSystemInfoSync() App({ globalData: { isIOS: systemInfo.system.indexOf('iOS') > -1, isWeChat: systemInfo.platform === 'devtools' ? false : true, // 模拟器平台为devtools statusBarHeight: systemInfo.statusBarHeight } })

所有涉及顶部导航栏高度的组件，都用isIOS和statusBarHeight计算，彻底告别“模拟器正常，真机错位”。

第二招：网络层埋点监控
在utils/request.js中统一拦截：

const request = (url, options = {}) => { console.log(`[API] ${url} start`, new Date().toLocaleTimeString()) return new Promise((resolve, reject) => { wx.request({ url, ...options, success: res => { console.log(`[API] ${url} success`, res.data, new Date().toLocaleTimeString()) resolve(res) }, fail: err => { console.error(`[API] ${url} fail`, err, new Date().toLocaleTimeString()) reject(err) } }) }) }

真机测试时，打开微信开发者工具的“Console”，所有API调用时间、参数、返回值一目了然，再也不用猜“是前端没发请求，还是后端没响应”。

第三招：离线能力兜底
所有关键操作（如扫码录入、订单提交）都实现离线缓存：

// 扫码成功后，先存本地 wx.setStorageSync('pendingScan', { materialCode: '123456', timestamp: Date.now() }) // 网络恢复时自动同步 wx.onNetworkStatusChange(res => { if (res.isConnected) { const pending = wx.getStorageSync('pendingScan') if (pending) { // 调用云函数提交 cloud.callFunction({ name: 'submitScan', data: pending }) wx.removeStorageSync('pendingScan') } } })

五金厂仓库网络不稳定是常态，这个兜底方案让客户满意度提升40%。

7. 给后来者的三条铁律：别让AI成为你的遮羞布

写到这里，必须说点扎心的话。这18.6万行代码背后，是我删掉的237次无效生成、重写的89个组件、熬过的42个通宵。AI不是魔法棒，而是把关人。以下三条，是我用真金白银换来的教训：

第一，永远先画流程图，再喂提示词
曾有个采购员说：“我要个能查库存的页面。”我直接让AI生成，结果出来个带搜索框的列表页。上线后才发现，他真正想要的是“输入物料号，显示该物料在所有仓库的实时库存+最近3次出入库记录+供应商联系方式”。如果当时我先用纸笔画出这个流程，再把流程图拍照喂给AI，生成质量会高十倍。流程图是业务语言到技术语言的唯一可靠翻译器。

第二，真机测试不是最后一步，而是每一步
我见过太多人，在模拟器里调通就宣布完成。结果真机一扫，顶部导航栏遮住胶囊按钮，输入框聚焦时页面被顶飞，扫码后内存暴涨崩溃。我的做法是：每个组件生成后，立即用三台真机（iPhone、华为、小米）各测3次，记录失败率。失败率＞5%，立刻重构提示词，而不是调代码。

第三，把“不会写代码”变成你的护城河
程序员容易陷入“这个功能怎么实现”，而业务人天然关注“这个功能解决什么问题”。我故意不学JavaScript，就是为了保持这种视角。当AI生成一个炫酷的3D库存看板时，我会问：“采购员在仓库拿着手机，需要3D旋转看螺丝库存吗？还是需要一眼看到‘M8螺栓还剩237件，安全库存是500件，建议补货’？”——答案永远是后者。你的“不懂”，恰恰是过滤技术噪音的最强滤镜。

最后分享个细节：项目交付那天，五金厂老板握着我的手说：“张工，你这系统比之前花80万买的ERP还好用。”我没告诉他，这系统里没有一行代码是我写的，但每一行代码，都刻着我对他们车间、仓库、办公室的观察，对采购员手指茧的位置、对财务总监皱眉的频率、对老板深夜看报表时的叹息的理解。AI只是锤子，而你是挥锤的人。锤子再快，也敲不出你心里没有的形状。