内容说明：这是一个已经投入实际使用的个人项目。代码和文章均有 AI 参与，我负责需求判断、功能取舍、部署排查和最终验收。为保护家人和实际使用者的隐私，文中省略了工作室名称、客户数据和后台地址。
起点不是“我想做一个产品”
家人从事室内设计，原来一直用第三方问卷收集装修需求。我经常看到她把链接发给客户：页面带着平台广告，四十多道题挤在一起，选了“不需要某项功能”，后面仍然可能继续追问；“现代简约”“侘寂”“复古南洋”这些文字对设计师很清楚，对客户却未必意味着同一件事。
我最初只想解决三个很小的问题：页面看起来像自己的、手机上愿意填、收回来以后真的方便阅读。它不是创业计划，也不是为了证明我会写代码，而是一个就在身边、每天都能看见的不合理流程。
后来项目从一个下午的原型，逐渐扩展成轻量版、完整版、后台、AI 分析和多用户版本。代码库在一个月左右留下了 57 次提交、43 个页面与接口路由。数字本身不代表价值，但它至少说明：真正的工作远不止“让 AI 生成一个表单”。
第一层判断：不是所有客户都该填同一份问卷
刚接触的客户，可能连是否装修都没有确定；已经准备量房的客户，则需要认真讨论家庭成员、空间使用、预算和材料偏好。让两类人填写同样深度的问卷，只会在“信息不足”和“填写压力过大”之间二选一。
现在的轻量版有 5 个模块、21 道题，用于第一次深入沟通前的快速摸底；完整版有 9 个模块、77 道题，覆盖家庭结构、生活方式、审美、厨房卫浴、卧室、收纳、设备和服务预期等内容。
两份问卷不是简单的一长一短。轻量版追求的是：用最少问题判断项目是否成熟、还有什么必须追问；完整版追求的是：在设计工作真正开始前，尽量减少“做到一半才发现理解错了”的返工。
第二层判断：问卷收集的不是答案，而是信号
如果只是把题目按页面顺序存下来，最终得到的仍然是一长串零散回答。我后来给问题重新做了一次“信号地图”，把它们归到几类真实决策需要的信息：
- 项目范围、当前阶段和时间紧迫性；
- 预算层级与需求是否匹配；
- 家庭成员、生活方式和空间优先级；
- 风格、色彩和材质偏好；
- 最想解决的问题与最不能接受的结果；
- 服务期望、决策链和潜在沟通风险；
- 户型图、参考图和仍然缺失的资料。
这个整理带来了一个重要结论：问卷不能完全自由编辑。
如果允许使用者随意删除预算、家庭结构、生活方式和项目阶段等问题，页面当然更“灵活”，但后面的分析会失去依据。因此多用户版本采用的是三层结构：固定核心信号不能删除，厨房、卫浴等专项内容可以按需要开启，使用者还可以增加自己的补充问题。
这件事对任何“问卷 + AI”产品都适用：先定义哪些信息是推理成立的最低条件，再谈自由配置。
第三层判断：AI 不应该把信息不足伪装成洞察
问卷提交后，系统先把回答整理成结构化画像，再基于画像和原始回答生成阅读报告。两阶段处理比直接让模型写一篇长文更容易检查：第一阶段关注事实和缺失项，第二阶段才组织风险、矛盾和下一步沟通建议。
但更关键的是，21 题和 77 题不能输出同样确定的结论。
轻量版只够做初步侧写，因此分析被要求降低确定性，多使用“待确认”，并把重点放在下一次应该追问什么；完整版信息覆盖更广，可以给出更具体的设计与沟通建议，但缺少证据时仍必须明确保留不确定性。
我最初把 AI 客户侧写当作最有价值的功能。实际使用以后，我更愿意把它定义为“阅读辅助”：它能减少设计人员从几十道回答里提取线索的时间，却不能替代人与客户沟通，也不应该把模型推测包装成客户的真实心理。
图片优化比模型选择更直接地影响体验
最早的 13 张装修风格参考图都是 PNG，总体积接近 48MB。桌面宽带下还能忍受，客户从微信里用手机打开时，等待足以让整个问卷失去意义。
后来把图片统一缩到 400 像素宽并转成 JPEG，总体积降到约 580KB。这里没有复杂技术，只有一个容易被忽略的产品判断：这些图片的任务是帮助客户区分氛围，不是提供可以放大检查材料纹理的高清图库。
从 48MB 到 580KB，比换一个更强的模型更直接地改善了使用体验。
从单人自用到多人使用，难点不是多一个登录框
系统实际使用后，我尝试让其他设计人员也能拥有自己的问卷。页面改成多用户并不难，真正必须确认的是：
- 每份问卷属于谁；
- 每次提交写入哪个使用者名下；
- 登录后是否只能看到自己的客户资料；
- 自定义问卷重新生成分析时，读取的是不是它自己的题目；
- 停用一个账号时，公开问卷、历史提交和附件应该如何处理。
验收时必须使用第二个账号反向测试：一个设计人员提交的数据，另一个账号不能看到。没有这一步，“支持多用户”只是界面描述，不是已经成立的数据隔离。
我最终没有开放公开注册、在线支付和完全自由的问卷编辑，而是保留人工开通。因为当时真正需要验证的是有没有人愿意持续使用，不是能不能把 SaaS 功能表全部做齐。
上线不是页面能打开
部署时曾出现服务器本机访问正常、经过域名却一直失败的情况。我最初围绕反向代理和程序配置排查，最后通过网络抓包确认，请求根本没有进入服务器：问题在云服务商控制台的外层防火墙。
后来又补了两级健康检查：高频的只读检查确认页面和问卷配置能够访问；低频的完整探针则真的创建一份标记过的测试提交，再读取并删除，用来验证“打开页面”之外的数据库写入链路。
目前这个项目仍有明显不足：主要依靠验收清单和线上探针，尚未建立与功能规模相称的自动化测试套件。这也是如果继续对外提供服务，必须优先补上的部分。
为什么没有继续商业化
技术上，它已经可以从单一自用工具扩展成多设计人员平台；商业上，它什么都没有证明。
我没有认真推广，也没有验证收费方式。即使有人愿意付费，客单价可能也不足以覆盖持续获客、客服、数据安全和模型调用成本。在缺少主动询问和付费意愿之前，继续加入支付、套餐和复杂运营功能，只会把一个有效的自用工具变成需要长期供养的产品。
所以它目前最准确的身份仍然是：为一个真实需求做出的自用工具，附带完成过一次产品化实验。
这次项目真正教会我的东西
AI 可以很快生成页面、接口和数据库代码，但它不会替我决定：
- 哪些问题值得问，哪些只是增加填写负担；
- 什么信息不足以支撑一个结论；
- 自由配置和结果可靠性之间如何取舍；
- 多用户功能什么时候才算真的隔离；
- 一个技术上能继续扩展的项目，是否值得继续投入。
这些判断比“半天做出一个系统”更慢，也更值得记录。项目没有证明我是一名专业开发者，也还不是一门生意；它证明的是，我可以把一个模糊的不满拆成实际规则，借助 AI 做出可运行版本，再用真实使用决定什么应该保留、什么应该停止。