用 AI 改造真实工作，而不是为了 AI 而做 AI。

我是工程建设行业的标书人员，也是一名计算机专业毕业生。

开发 AI Bid Assistant，并不是为了“做一个 AI 项目”，也不是为了追赶某个技术热点。

真正的起点很简单：

每天面对大量招标文件、开标节点、资格要求和重复整理工作时，我希望把时间和精力留给真正需要判断的事情。

今天没有新增一堆炫技功能。

整个过程更像一次真实的软件迭代：

1
2
3
4
5
6
7
8
9

分析问题
   ↓
补齐刚需
   ↓
优化体验
   ↓
主动停止开发，进入稳定使用阶段
   ↓
整理踩坑经验

写下这篇文章，记录这一天，也给那些想用代码改善自己工作的人一些参考。

一、这个项目为什么诞生？

工程建设行业的投标工作，有很多重复但又不能出错的事情。

日常工作大概是这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

收到招标文件

      ↓

阅读几十甚至上百页 PDF

      ↓

寻找：
- 开标时间
- 保证金要求
- 资格条件
- 废标条款
- 技术要求

      ↓

整理到自己的表格和笔记

      ↓

等待项目推进

看似简单，但实际痛点很多。

1. 信息分散

招标文件很长：

• 开标时间可能在公告页
• 保证金可能在须知章节
• 资格要求可能在投标人条件里
• 废标条款可能隐藏在评分办法中

关键信息经常散落在几十页甚至几百页文字里。

2. 多项目并行，节点容易遗漏

同时跟进多个项目时：

• 哪个项目快开标？
• 哪个保证金还没处理？
• 哪个项目资格条件特殊？

很多时候依靠的是个人记忆。

3. 行业经验与技术能力之间存在错位

懂投标流程的人：

可能不会开发工具。

会写代码的人：

又不了解真实投标场景。

于是产生了一个机会：

让行业经验和软件技术结合。

AI Bid Assistant 是什么？

它目前是一个：

面向工程建设行业标书人员的智能投标工作台。

技术形态：

1
2
3
4
5

纯前端
+
Supabase
+
用户自备 OpenAI 兼容 API

核心能力：

• 项目管理
• 开标节点提醒
• 浏览器内 PDF 解析
• AI 提取招标关键信息
• 废标风险辅助分析

隐私设计：

• 招标文件不会上传到项目服务器
• AI Key 只保存在用户本机

最初版本大约处于 v0.2：

已经有：

• 登录
• 云端同步
• 项目列表
• 搜索筛选
• PDF 解析
• AI 分析

功能已经够用。

但距离“敢长期依赖它”，还有一些距离。

二、先分析问题，而不是继续堆功能

在继续开发之前，我先做了一次偏产品和工程角度的检查。

已经比较好的地方

1. 场景真实

最大的优势：

它不是为了展示 AI 能力而创造的。

它来自每天真实工作的痛点。

2. 数据结构接近业务

项目字段直接对应实际工作：

• 开标时间
• 招标单位
• 投标公司
• 保证金
• 项目状态
• 风险信息

不是为了技术展示设计出来的字段。

3. 基础工程设计合理

包括：

• 模块化代码
• 用户数据隔离
• 密钥不进入仓库
• AI 结果回填项目数据

已经具备一个长期工具的基础。

优先补充的问题（P0）

相比增加新功能，更重要的是让已有功能可靠。

主要调整：

增加常用字段

补充：

• 招标单位
• 项目金额

这些信息在真实工作中经常查看。

结构化 AI 输出

之前：

1
2
3

资格要求
废标条款
全部塞入备注

问题：

• 难搜索
• 难展示
• 难继续处理

调整后：

1
2
3
4
5
6
7

资格要求
      ↓
结构化字段

废标风险
      ↓
独立展示

优化长文档 AI 分析

之前：

长文本直接截取。

问题：

招标文件越长，分析质量越不稳定。

调整：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

长文档

 ↓

分块摘要

 ↓

整体汇总

 ↓

结构化提取

并增加失败自动重试。

补齐工程基础

包括：

• .gitignore
• 版本记录
• 维护文档

三、两轮实际改动

第一轮：P0 —— 从“能用”到“敢用”

完成：

✅ 增加招标单位
✅ 增加项目金额
✅ 资格要求独立展示
✅ 废标风险独立展示
✅ AI 长文档分块处理
✅ 增加失败重试
✅ 完善项目文档

实际跑了一轮后：

最大的感受不是“功能更多”。

而是：

使用过程中更安心了。

第二轮：P1 —— 只优化体验

没有继续扩展功能。

只改两个每天都会遇到的问题。

1. 开标提醒可配置

之前固定提醒。

现在：

1
2
3
4
5
6
7

提醒范围：

1～30 天

默认：

7 天

设置保存在本机。

2. 移动端体验优化

因为工作中经常需要：

“拿手机快速看一下项目”。

所以调整：

• 表单间距
• 列表密度
• 统计布局
• 按钮点击体验

这些变化不大。

但对日常使用很重要。

四、一个比增加功能更重要的决定

当系统已经能够支撑日常工作后，我做了一个决定：

暂时停止扩展功能。

先长期使用。

再决定下一步。

很多个人开发项目容易陷入：

1
2
3
4
5
6
7

开发
 ↓
增加功能
 ↓
继续开发
 ↓
永远没有完成

但真正有价值的软件：

不是功能最多。

而是：

用户愿意每天打开它。

因此，我重新整理了项目文档。

README

去掉大量：

• 长期愿景
• Roadmap
• 未来规划

只保留：

• 它是什么
• 当前有什么能力
• 如何运行
• 如何部署
• 安全注意事项

文档整理

调整：

• Changelog 保留完整历史
• 维护说明保持简洁
• 当前版本明确标记

当前稳定版本：

1

v0.2.5

对于个人项目来说：

写得完重要，收得住同样重要。

五、Git 与 PowerShell 的小插曲

最后提交代码时，在 Windows PowerShell 中踩了几个典型坑。

记录下来。

1. 多行 commit message 不要直接复制到终端

错误方式：

1
2
3
4

git commit -m "标题"

- 第一条说明
- 第二条说明

PowerShell 会把：

1

-

当成运算符解析。

导致：

1

一元运算符后面缺少表达式

这些内容不会进入 commit。

正确方式：

1
2
3
4
5
6

git commit -m @"
标题

- 说明一
- 说明二
"@

或者：

直接：

1

git commit

进入编辑器填写。

2. reset –soft 后不要误用 amend

例如：

1

git reset --soft HEAD~1

含义：

撤销最近一次提交，但保留代码。

此时如果：

1

git commit --amend

修改的是更早的提交。

如果只是重新提交：

应该：

1

git commit -m "新的说明"

3. 历史修改后 push 被拒绝

出现：

1

non-fast-forward

说明：

本地和远程历史已经不同。

个人仓库确认没有其他协作者时：

可以：

1

git push --force-with-lease

相比：

1

git push --force

更安全。

一个简单原则：

1
2
3
4
5
6
7
8
9

还没 push：

可以 amend


已经 push：

尽量新增 commit
不要修改历史

六、这一天得到的几个原则

1. 从自己的重复劳动出发

比研究：

“AI 还能做什么？”

更容易做出真正有价值的工具。

2. 先补可靠性，再谈生态

很多时候：

增加一个字段。

优化一次数据结构。

比增加一个“AI生成按钮”更有价值。

3. 主动进入稳定期

软件不是永远开发中的半成品。

真正成熟的工具：

应该进入长期使用阶段。

4. 工具链也是产品的一部分

Git：

• 提交记录
• 分支管理
• 历史维护

这些看似和用户无关。

但决定了项目能否长期维护。

七、写在最后

AI Bid Assistant 已经开源在 GitHub：

1

github.com/chenduowei/ai-bid-assistant

它的技术并不复杂：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HTML
CSS
JavaScript 模块化开发

+

Supabase

+

用户自己的 AI API

真正复杂的是：

业务细节。

比如：

• 开标节点
• 废标风险
• 提醒窗口
• 手机查看体验

这些东西，不使用的人很难设计出来。

接下来一段时间：

我不会急着开发：

• 企业资料库
• 自动生成标书
• 复杂协作系统

而是：

先成为这个工具最重度的用户。

真正每天反复遇到的问题，才值得进入下一版本。

如果你也想用代码改善自己的工作流程，我认为路径可以很简单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

发现痛点

↓

做一个小工具

↓

真实使用

↓

记录问题

↓

继续优化

不要为了 AI 而做 AI。

用 AI 改造真实工作。

这才是技术真正有价值的地方。