这份记录整理一次真实的非开发者 + AI 编程协作经历，供后续贡献者参考。它不是方法论定论，只是本项目形成过程中的可复盘经验。
项目发起人最初只提供了产品想法：面向阅读学习，用摄像头视线追踪记录阅读过程，再让 AI 生成更贴近真实阅读轨迹的笔记。早期尝试中，仅靠这个方向性描述没有跑通可用软件。
后续再次尝试时，项目发起人补充了更具体的实现方案和技术选型原则：
- 阅读页要先被识别或渲染成可和屏幕位置对应的文本区域。
- 视线轨迹必须带时间戳，并能和文本区域叠合。
- 需要保存每页的阅读行为摘要，再结合原文和笔记需求交给 AI。
- 技术选型要优先降低配置要求、降低阅读过程噪音，并注意开源许可。
- 视线追踪优先尝试 GazeFollower。
- 先做 MVP，再在 GitHub 开源共建。
在这个更明确的约束下，Codex 负责把方案落成代码：搭建 FastAPI 后端、固定翻页阅读器、PDF 渲染与文字框提取、GazeFollower 采样、证据面板和 AI 辅助笔记生成，并通过多轮测试和用户反馈修正问题。
不能简单归因于模型升级。更强的模型和更好的本地工具能力确实重要，但这次跑通还依赖几个因素：
- 项目发起人把“想做什么”推进到了“可能怎么做”：页面文字定位、视线时间戳、轨迹叠合、页级映射、AI 输入结构。
- 技术选型从开放问题收敛为可执行边界：本地 Web MVP、GazeFollower、先支持常见文档、优先降低配置压力。
- 用户持续试用并指出具体问题：启动慢、摄像头释放、翻页延迟、阅读范围提交过大、滚轮翻页、证据混合等。
- Codex 能访问本地代码、运行命令、改文件和跑测试，所以可以反复把抽象想法压到可运行状态。
- 项目没有把 AI 输出当成最终事实，而是通过测试、证据面板和文档边界不断收紧风险。
因此，更准确的说法是：模型能力提升提供了更强执行力，但清晰的实现假设、技术边界、用户反馈和可验证测试共同决定了这次能跑通。
如果你不是程序员，但想和 AI 做一个未被充分开发的产品原型，可能比“写一个万能提示词”更有用的是：
- 先说明真实使用场景，而不是只说功能名。
- 尽量提出一条逻辑上可行的数据路径：输入是什么，中间要变成什么，最后交给谁处理。
- 写清技术约束：本地还是云端、是否涉及隐私、配置要求、许可边界、先做什么格式。
- 允许 AI 调整实现手段，但要保留你的产品假设。
- 让 AI 每次改完都跑测试或做可观察验证。
- 自己负责体验判断：哪里不自然、哪里不可信、哪里和原始目标偏离。
在这个过程中，AI 更像“能快速试错的工程合作者”，而不是凭空替你发明完整产品的人。非开发者的价值不只是给一句灵感，而是持续提供使用场景、边界、取舍和验收标准。
- 具体方案不等于产品已经被证明有价值，仍需要真实用户测试。
- AI 生成代码可能隐藏错误，必须通过测试、代码审查和公开协作改进。
- 对涉及摄像头、阅读行为和学习状态的功能，要避免过度承诺，尤其不要把行为线索写成心理或医学判断。
- 文档应区分“已实现”“半成品”“研究中”和“未来方向”，避免让贡献者误解项目状态。
- LLMs' Reshaping of People, Processes, Products, and Society in Software Development：早期使用者报告 LLM 能减少重复工作、加速调试，但也强调人工判断、分层验证和安全集成仍然必要。
- The Use of AI in Software Engineering：综述 AI 在测试、维护、需求提取、漏洞检测和教育等软件工程活动中的应用。
- Human-AI Collaboration in Software Engineering：讨论人机协作在软件工程中的能力、限制和实践经验。