编程小白也可以做项目，AI 辅助开发太香了
一个只有项目管理经验、编程基础"半桶水"的人，在 AI 的帮助下从零做出了两个医疗数据开源工具，其它正在探索中。
先说背景：我的编程水平
我是做项目管理的，写代码这件事——坦白讲，水平很一般。会一点 HTML/CSS，看得懂简单的 Python 和 JavaScript，偶尔用用SQL，API 大概明白是"系统之间传数据的管道"这个层面。如果让我手写一个完整项目，那基本不现实。
但我在医疗信息化行业干了多年，太清楚医院数据层面的痛点了——系统之间数据不通、外送化验单 PDF 堆成山无法检索、各种接口扯皮……这些痛点一直都在。
2026 年 5月，开始关注Coding Agent。抱着"试试看"的心态入了坑，没想到这一试，直接打开了新世界的大门。
时间线总览
2026 年 5 月 AI 辅助开发初体验：HospitalStats
从一句话的需求到 .NET 查询引擎落地
解决了 Oracle US7ASCII 中文乱码 + ROWNUM 分页
2026 年 7 月 第二个项目：Lab2FHIR
4 天 42 次提交，404 份 PDF 化验单 → FHIR R4
全流程 AI 辅助：架构设计、代码、测试、文档
2026 年 7 月 搭建 is81.net 门户站
纯静态 HTML/CSS/JS，统一设计系统
给两个项目一个"家"
2026 年 7 月 ProjectX，继续用 AI 探索新方向……
项目一：HospitalStats —— 和中文乱码死磕，用时约7天
痛点从哪来
医院经常有上级检查，临床科室也经常有数据查询需求，我就有了做一个“东西”的想法，那时候还没有完整的思路，只有大概的方向：把上级检查、临床科室常用的查询需求做进这个“东西”里，不就可以节约大量重复劳动时间吗？不过那时候我一个人完成不了，也就只停留在“想想”阶段。我们用的 Oracle 11g 数据库，字符集是 US7ASCII。这玩意儿有个致命问题：只要数据库字符集是 US7ASCII，传输层就会把所有超出 ASCII 范围的字节替换成问号。患者姓名变成 ???，药品名称变成 ????，诊断信息全毁。
更头疼的是，Oracle 11g 没有 OFFSET/FETCH 语法，做分页查询得手写三层嵌套 ROWNUM 子查询。每来一个查询需求，都是一场噩梦。
AI 辅助开发过程
我不懂 .NET，不会 C#。但我知道要解决什么问题。
我的做法很简单：
- 把需求拆成自然语言：跟 AI 说清楚"我想做一个东西，大概功能是什么什么，用 Oracle 11g 数据库，字符集是 US7ASCII"
- AI 给出方案，我来判断：AI 会先给你列个计划，然后经过跟你的探讨后开始执行，遇到乱码会解释为什么会有这个问题（US7ASCII 编码层的字节替换），然后给出几种解决思路。我有项目管理的经验，能判断哪种方案更"靠谱"——比如纯本地运行比依赖第三方库更符合医院内网环境。
- 迭代式对话：AI 写代码，我跑起来测试，出错了把报错信息贴回去，AI 继续改。如此循环。
- 给 AI"穿鞋"：Claude Code 的 CLAUDE.md 文件就像给 AI 的项目手册，我把项目的约束条件（内网部署、Windows 环境、越轻越好）写进去，AI 每次给方案都自动对齐这些约束。
结果呢？从初版的数据统计平台，到最终归纳为一个 36KB 的轻量 .NET 查询引擎，完成了以前我想都不敢想的工作。
作为 PM 的经验发挥了什么作用？ 需求拆解、方案评估、风险把控、交付标准——这些完全是 PM 的日常技能。写代码交给 AI，但"做对的东西"这件事，靠的是项目管理思维。
项目二：Lab2FHIR —— 4 天 42 次提交，从零到上线
又一个医院痛点
病理科每个月产生 400+ 份外送化验/病理 PDF 报告——DNA 倍体分析、TCT 液基细胞学、HPV 分型检测、胃镜病理、外科病理……这些 PDF 文件散落在文件服务器上，无法检索、无法统计、无法与 HIS/EHR 系统互通。
临床医生想查病人历史报告，得在文件夹里翻半天。病理科想按疾病类型统计发病率？一个一个打开 PDF 手动数吧。
"4 天 42 次提交"是怎么做到的
有了第一个项目的经验，这次我更有章法了。整个开发流程是这样的：
Day 1：跑通核心链路
先不管界面好不好看、功能完不完整，先把最关键的事做了——能不能把 PDF 里的文字准确提取出来？花了半天验证 pdfplumber 能把患者姓名、性别、年龄、病理号、诊断结论准确拿到。只要核心链路通了，心里就有底了。
Day 2：6 种报告类型全覆盖
不同报告的格式千差万别。DNA 报告要提取 DI 值、SPF 值和染色体状态，胃镜病理要提取慢性炎症、活动性、萎缩、肠化四项评分。关键是报告类型先识别、再解析——这里有个坑：胃镜病理和外科病理的报告抬头都写"病理诊断报告单"，如果先匹配"病理诊断"，胃镜就被错误归类了。解决方法很简单：胃镜特征词优先检查，病理诊断兜底匹配。
这个"优先级匹配"的思路，是我跟 AI 来回讨论时一起想出来的——我懂业务逻辑（胃镜报告有哪些特征词），AI 懂代码实现（怎么写优先级解析器），配合得天衣无缝。
Day 3：FHIR 标准化输出 + 前端
FHIR R4 是国际医疗数据交换标准，配 LOINC 编码映射。这是整个项目对外价值的核心——有了 FHIR，数据才能对接 HIS、参与互联互通。AI 帮我生成了完整的 DiagnosticReport + Observation Bundle 结构。
前端用 Vue 3 + Element Plus，做了一个三栏对照布局：左边是解析后的结构化数据，中间是 PDF 原文，右边是 FHIR JSON(可以隐藏)。用户边看原文边核对，一目了然。
Day 4：测试 + 部署
404 份真实 PDF 样本全部通过，诊断提取成功率 100%。FTS5 全文搜索 6 毫秒响应。用 nssm 注册成 Windows 服务，nginx 反向代理，开机自启——医院信息科同事只需要双击一个安装脚本。
我的项目开发流程（AI 辅助版）
经过两个项目，我摸索出了一套适合"非专业开发者 + AI"的流程：
1.挖痛点 → 2.定范围 → 3.跑核心 → 4.螺旋式 → 5.收尾
第一步：挖痛点（PM 的老本行）
问自己三个问题：
- 谁在痛？（病理科医生？临床医生？信息科？）
- 痛多久了？（是"忍忍就过去了"还是"每天都想骂人"？）
- 我能不能解决？（技术复杂度、数据可获得性、部署环境约束）
这一步完全不需要写代码，但决定了后面所有工作的方向。PM 的经验在这里是最大的优势。
第二步：定范围（用 AI 帮忙梳理）
把痛点描述给 AI，让它帮你梳理成结构化的需求清单。注意：AI 给出的需求可能很"理想化"，你需要用领域知识做减法。
比如 Lab2FHIR，AI 一开始建议上 OCR（因为很多 PDF 是扫描件），但我看了实际样本后判断——这 404 份全是文本型 PDF，pdfplumber 就够了。砍掉 OCR 省了至少一周的开发时间。
原则：够用就好，别被 AI 带偏。
第三步：跑通核心链路（最重要的里程碑）
先做最小可行原型。一个 API 端点、一个能跑的函数、一个能看的页面——什么都行，但一定要"从头到尾跑通"。
为什么这一步最关键？因为：
- 证明了技术上可行（不会开发一半发现死胡同）
- 给了自己信心（"我靠，真的能跑！"）
- 给 AI 提供了"地基"（后续迭代都在这个基础上叠加）
第四步：螺旋式迭代（AI 的强项）
核心链路通了，接下来就是一圈一圈往外扩。每一轮迭代：
- 我描述"这一轮要加什么功能"
- AI 生成代码
- 我跑起来验证
- 出问题 → 贴错误信息给 AI → AI 修复 → 回到步骤 3
- 功能 OK → 提交 commit → 开始下一轮
Lab2FHIR 的 42 次提交就是这么来的——每 1-2 小时一个可工作的增量。以前写代码是"憋大招，一次上线"，现在是"小步快跑，持续交付"。
第五步：收尾交付（别忽略的门面）
代码能跑 ≠ 项目做完了。这一步包括：
- 部署脚本（一键安装，降低使用门槛）
- 生产环境验证（需求部门用真实数据验证）
- 写 README 和文档（AI 帮忙生成，我审核修正）
- 开源协议选择（MIT 还是 AGPL，想清楚）
- 做产品页（is81.net 上的项目介绍页）
项目间的"知识复利"
做完 HospitalStats 再做 Lab2FHIR，我发现一个有意思的现象：AI 辅助开发的效率是递增的。
第一个项目时，我还在摸索怎么跟 AI 沟通——描述需求的方式、报错信息的回传格式、什么时候该信任 AI、什么时候该质疑它。磕磕绊绊，但做出来了。
第二个项目，我已经形成了自己的工作流。CLAUDE.md 里沉淀了项目的设计系统和部署约束，AI 一上来就"懂"我的上下文。各种有用的Skills也装上了。4 天 42 次提交，这个速度在一年前我完全不敢想象。
现在探索其它痛点，效率只会更高——因为每个项目的经验（技术选型、部署方案、设计系统、甚至 prompt 技巧）都在喂养下一个项目。
这不是 AI 在替代我，而是我和 AI 一起在变强。
给同样"小白"的你几条真心话
1. 你有"非技术优势"
项目管理经验让你懂需求分析、懂范围控制、懂风险判断。这些东西 AI 做不到，但写代码的人经常缺。你缺的是代码实现能力，AI 正好补上了这块短板。
2. 从真实的痛点出发
不要为了"学编程"而做项目，从你工作中真正烦人的问题出发。痛点越具体越好——"全院病理 PDF 没法检索"比"我想做一个医疗数据平台"好一百倍。
3. 先跑通，再完美
MVP 先行。看到一个端点返回正确数据的那种喜悦，是支撑你继续往下走的最强动力。
4. AI 是副驾驶，你才是机长
AI 会写出看起来很漂亮的代码，但判断它"对不对"的是你。领域知识、业务逻辑、部署环境约束——这些关键决策 AI 给不了，得你自己把握。
5. 把每一次对话当成"项目文档"
建一个 CLAUDE.md 或类似的上下文文件，把项目的设计决策、约束条件、技术选型理由都写进去。这不只是给 AI 看的——三个月后你自己回头看，也会感谢现在的你。
第三个项目：ProjectX，探索继续
HospitalStats 解决了数据"出不来"的问题，Lab2FHIR 解决了报告"不标准"的问题。
ProjectX 在探索什么？还没想好。但可以肯定的是——这次的开发速度只会更快，因为我和 AI 的默契又上了一层。
如果你也是一个"想做事但觉得自己不会写代码"的人——AI 工具已经足够强了，强到可以补上你缺的那块技能板。你只需要带着你的领域知识和解决问题的决心，就可以开始了。
is81.net —— 一个 PM 用 AI 做的医疗数据开源工具站
GitHub: github.com/is81
交流: is81@qq.com
浙公网安备 33010602011771号