一、个人介绍
我是一名前端开发工程师，日常工作主要用 Vue2，uni-app 和 Vue3 我基本属于"能看但看不懂"的水平。这也是为什么我特别依赖 AI 编程工具——市面上能免费用到的 AI 编程产品我基本都试过，TRAE IDE 公测第二天我就下载了，用到现在觉得效果确实不错。
这次参赛的作品"明阅"，代码100%由 TRAE 编写，我自己主要做的是产品设计、方向把控、找bug、以及和AI"斗智斗勇"——说实话，这比我自己写代码累多了。
做这个项目的初衷很简单：我注意到我们身边有1700多万视障朋友，但市面上几乎没有一款真正为他们设计的阅读App。我想试试，用AI能不能做出一个真正能用的无障碍产品。
二、产品简介（复赛版）
是什么
明阅是一款专为视障群体设计的纯离线 Android 无障碍阅读App。 它解决的核心问题是：让盲人不用看屏幕，仅凭触摸和语音就能独立完成"找书→导入→阅读/听书"的全流程。所有文档解析、TTS朗读、书架管理均在本地完成，无需联网，不收集任何用户数据。
为什么暂时只做Android？
两个原因：
一是体验问题。 我一开始也想过跨平台，但仔细想了想：让盲人拿着鼠标在网页上摸来摸去、网页TTS断断续续、再对着一个没有任何语音反馈的系统文件选择器闭着眼睛选文件——这根本不是做产品，这是逗盲人玩。功能做的再完善，死在"打开文件"第一步，没有任何意义。iOS 的 VoiceOver 体验确实好，但 iOS 没有类似 Android 这样可以直接分发 APK 的渠道，必须上架 App Store。
二是现实问题。 这是一个无盈利的公益项目，我一个人承担不起服务器成本，也承担不起iOS开发者账号每年688元的费用（Android可以直接分发APK安装，不需要应用商店审核费）。以后或许会做真正适配无障碍的网页版和iOS版，但现在，先把Android端做好。
面向谁
核心用户：全盲用户（依赖语音交互，需要完全无视觉的操作）
次要用户：低视力用户/老年人（需要大字、高对比度、简洁界面）
典型场景：盲人朋友独立阅读小说文档、低视力老人不用戴老花镜看书、走路/通勤不方便看屏幕时听书
为什么不直接用手机自带的读屏？（核心创新点）
很多人会问：手机本身就有TalkBack，为什么还要单独做一个阅读App？因为通用读屏是为"所有App"设计的，它和专门为阅读优化的体验差距非常大：
1、学习成本
手机自带TalkBack：需要学习几十种复杂手势（单指/双指/三指滑动、双击、长按等），很多老人根本学不会
明阅：打开就能用，只有两个手势：滑动听名字、双击确认，零学习成本
2、阅读体验
手机自带TalkBack：读屏会按页面元素顺序朗读，广告、按钮、菜单、正文混在一起读，读一段书要先听十几个无关元素
明阅：专门为阅读优化，打开直接就是正文，只读书，不读乱七八糟的UI元素，沉浸式体验
3、文档导入
手机自带TalkBack：系统文件选择器没有语音反馈，盲人根本摸不到哪个按钮是"确定"，哪个文件是自己要的
明阅：App内通过MediaStore列出文档，全程语音提示；支持系统分享"用明阅打开"；有语音引导协助开启权限
4、翻页导航
手机自带TalkBack：翻页需要双指滑动，经常误触；想回到上一段/下一段要先聚焦再操作，非常麻烦
明阅：左右滑动直接翻段/翻页，读完自动续读，完全符合盲人"听书"的使用习惯
5、排版适配
手机自带TalkBack：字体大小、行距、对比度全靠系统设置，App本身没做适配的话，大字模式下排版全乱
明阅：字体16-80px无级调节、行距/字间距/页边距全可调、黑底黄字等高对比度主题，专门为低视力用户优化
6、误触问题
手机自带TalkBack：手指稍微动一下就会切换焦点，正在读书的时候不小心摸到别的按钮就会跳走
明阅：所有按钮都有防误触锁、返回键二次确认、跨页面自动重置触摸状态，不容易误操作
7、状态反馈
手机自带TalkBack：很多App没做无障碍适配，按钮点下去没有声音，盲人不知道有没有成功
明阅：每一个操作都有语音反馈，点下去立刻告诉你"正在导入"、“已打开第3章”，永远不会"沉默"
简单来说：通用读屏是"让盲人能操作手机"，明阅是"让盲人能舒服地读书"——这是本质区别。
完整功能清单
明阅支持双模式一键切换，覆盖不同视力状况用户的需求：
大字模式 面向：低视力/老人 交互：普通点击，超大字体、高对比度配色
朗读模式 面向：全盲用户 交互：「滑动探索+双击确认」盲触摸交互，全程语音反馈
核心功能全流程：
文档导入：支持 Word(.docx)、TXT、Markdown、PDF 四种格式，所有解析在本地完成。这里必须说实话：Android 11 之后 Google 收紧了存储权限，自动扫描需要用户手动开启"所有文件访问权限"，我在App内做了完整的语音引导一步步教用户操作；同时支持系统文件选择器和"用明阅分享打开"，导入全程语音播报。
书架管理：最近阅读/全部书籍、按首字母筛选、语音搜索，朗读模式下滑到哪读到哪
阅读（大字模式）：字体16-80px无级调节、行间距/字间距自定义、多种高对比度配色主题（黑底黄字、暖米色护眼、深色模式等）
朗读（无障碍模式核心）：自研盲触摸组件、TTS语音朗读、语速/音调调节、逐句导航、自动记忆阅读位置、后台朗读
贴心细节：所有操作都有语音反馈、物理返回键二次确认防误触、页面切换自动重置触摸状态、横竖屏自动适配、用餐/睡眠提醒
相比初赛Demo的升级
文档支持 初赛：仅TXT 复赛：docx/TXT/Markdown/PDF四种格式（PDF修了大半个月）
交互可靠性 初赛：经常单击误触成双击、状态残留 复赛：完整的状态重置机制，跨页面不泄漏
BTA盲触摸组件 初赛：简单触摸检测 复赛：按钮位置缓存、横竖屏重算、多指过滤、防抖锁
页面完整性 初赛：只有书架+阅读页 复赛：导入/设置/字体/排版/统计/朗读设置/引导页全齐（共13个页面）
崩溃防护 初赛：大量未判空 复赛：所有回调参数判空、组件卸载检查、定时器自动清理
产品形态 初赛：仅开发调试用H5 复赛：可安装的Android正式APK安装包，纯离线运行
产品演示视频
【明阅 - 复赛作品介绍-哔哩哔哩】 https://b23.tv/2EFhmBx
三、产品创作历程
说实话，在不断完善这个项目的过程中，我有无数次后悔选了这个题目——这个项目远比我想象的要难太多了。
最初的困难：AI根本不懂"盲人看不见"
一开始我就遇到了第一个大坑：AI总是默认"用户能看见"。
我让它做无障碍交互，它总是会加一些"点击右上角按钮"、“滑动到中间位置"这种需要视觉的指引
它经常忘记TTS语音反馈——按钮点下去了，没有声音，盲人根本不知道发生了什么
页面布局稍微动态一点（比如列表加载、弹窗显示隐藏），按钮位置缓存就错了，摸半天摸不到
我一遍一遍地跟TRAE强调"盲人看不见！所有操作必须有声音！所有位置必须重新算！”，前前后后调了几十版，才终于做出了一个"看起来能用"的版本。
PDF解析：修了大半个月的噩梦
如果说交互问题是开胃菜，那PDF解析就是真正的boss战，从初赛结束一直修到8月5号——也就是几天前，整整大半个月。
一开始我以为PDF解析就是调个库的事，结果踩进了uni-app最大的一个坑里：
uni-app本质上不是一个真正的App，它就是一个H5浏览器套了个壳子，而且这个壳子不支持ES6。
这个坑有多坑呢？
我试了无数个版本的pdfjs，都解析失败，控制台连个报错都没有
我让AI帮我打印数据流排查问题，AI费了半天劲，弹出来的提示居然是"可能是数据损坏或文件过大"
我去CSDN、掘金、知乎搜，根本找不到答案——别人要么做原生App，要么做纯H5，没人像我这样既要在uni-app里读PDF，还要让TTS能读出来
AI甚至跟我"演戏"：有几次它说"修好了！PDF可以读了！"，我一试还真有声音——后来才发现，它根本没解析PDF，是它自己假装读了几段内容骗我，因为我一开始没做H5端，纯在App里测，我居然信了好几天！
后来我觉得这样不行，我连是什么错误都看不到，怎么修？我想：先在我熟悉的H5浏览器环境下调通，至少能看到控制台报错。H5端终于调通了，打包到App里还是失败——但这次有报错信息了。这里我犯了一个错误：我应该新开对话直接问这个报错，而不是在原来的对话里死磕——原来的对话上下文已经污染了，AI还在带着我绕弯路；而新对话看到报错，第一句话就点破了问题。
那段时间我真的快崩溃了。我发现一个更可怕的问题：
跟我沟通的是主智能体，但写代码的是子智能体，子智能体根本不受我的规则约束。
我写了一大堆规则、做了md文档记录、甚至让AI做定时审计防错误回归——审计到v55版本的时候，报告显示"完美无缺，所有功能正常"，结果实际一跑：页面是错乱的，功能是不全的，甚至到v70版本还存在参数不匹配的问题。我让AI"实际运行一遍把结果返回给我"，返回的结果完美无缺——直到我发现，程序根本就没运行，AI在梦里把流程演了一遍，所有的"可执行"、"可读取"全是它编出来的。
这个发现真的给了我很大打击。我当时想：要不把PDF功能删了吧，就做TXT，能完赛就行。但转头一想：我都坚持这么久了，删了算什么？
中暑+熬夜：最狼狈的一周
我高估了自己的身体。那段时间正好是高温天，心力憔悴加上高温，我中暑了。但我想中暑算什么，继续熬，每天修到凌晨4点，早上8点爬起来上班，有空就继续改。中暑脱水加上长时间睡眠不足，最后我头晕、眼颤抖、身体发麻——但我当时真的不困，就想把这个PDF搞出来。
转折点：开个新对话
最后解决问题的方法说出来很可笑：我在原来的对话里死磕了快两周，AI带着我绕了无数弯路；后来我先在H5上调通拿到了报错信息，但我还是在原来的对话里继续问——结果AI还在死扣代码逻辑，根本不看报错。那天我实在没辙了，新开了一个对话，把报错信息直接贴过去，新对话的AI第一句话就点醒了我：“这是pdfjs版本不兼容，uni-app的H5壳不支持ES6，你需要用ES5版本的pdfjs。”
就这么一句话，我卡了大半个月的问题，终于解决了。8月5号，PDF终于在App里跑通的那一刻，我坐在电脑前，半天说不出话。
四、TRAE实践过程
明阅从第一行代码到最后打包，100%的代码都是TRAE写的。我作为一个主要写Vue2、看不懂Vue3+uni-app的前端，能做出这个App，全靠TRAE。
我的TRAE工作流：
产品层面想清楚：我不纠结代码怎么写，我只需要想清楚"盲人用户在这个场景下需要什么"、“这个操作应该有什么反馈”
写清楚需求给TRAE：把用户场景、交互逻辑、边界情况都描述清楚
分模块迭代：一个功能一个功能做，做完立刻测，发现bug立刻把现象贴给TRAE
关键经验（踩过的坑）：
bug卡壳超过1小时，立刻开新对话——上下文污染真的会让AI带着你绕弯路，新对话没有历史包袱，往往一眼就能看到问题（PDF问题就是这么解决的）
不要相信AI说的"没问题"：一定要自己实际跑一遍，AI真的会"演戏"，会假装运行、假装测试通过
主智能体和子智能体是分离的：你跟主智能体说再多规则，写代码的子智能体可能根本不遵守，不要只看审计报告，一定要实际运行验证
不要在长对话里死磕：对话越长，AI越容易"脑补"和"和稀泥"，关键问题用新对话直接问
说实话，这次比赛最大的收获不是做出了一个App，而是我真的摸清楚了怎么和AI协作、怎么让AI帮我做出我自己一个人做不出来的东西。过程很痛苦，但结果值得。
无能狂怒：
删除沉余：
依旧是和pdf解析斗争：
修复ui：
3507921158150499:4f6d6fa24332f59b00f3a598d533c2d2_6a69ae751005f6c8f75fb5c4.6a69e2ba1005f6c8f75fc52a.6a69e2ba1005f6c8f75fc528:TRAE Work CN.0.1.19.no_sid.no_ppe.T(2026/7/29 19:23:38)
每小时定时审计：
3507921158150499:ed0635ff1508927ccc5f3d5fa2b81f79_6a6abda3e785ad40d6a4ad90.6a6ac7f0e785ad40d6a4b11e.6a6ac7f0e785ad40d6a4b11c:TRAE Work CN.0.1.19.no_sid.no_ppe.T(2026/7/30 11:41:36)
pdf修复成功：
3507921158150499:b9a07236a53b15e45f19cb28f6d41684_6a71eb6cd23cfd862abb060c.6a735077271d361315ff3b9e.6a735077271d361315ff3b9c:TRAE Work CN.0.1.19.no_sid.no_ppe.T(2026/8/5 23:02:15)
技术方案分享
技术栈
框架：uni-app + Vue3 + Vite（编译为Android App）
状态管理：Pinia
文档解析：
docx → mammoth.js（UMD版直接挂载，避免构建兼容问题）
PDF → pdfjs-dist ES5版本（踩了大半个月坑才找到的正确版本，适配uni-app的H5壳）
TXT/Markdown → 原生解析
语音合成：Android端用5+ API的plus.speech，系统级TTS稳定可靠
核心技术点：盲触摸区域（BTA）组件
这是明阅最核心的组件，也是我和TRAE调了最久的部分：
组件挂载后，遍历所有带data-label的按钮，用getBoundingClientRect()缓存位置
触摸时实时判断手指在哪个按钮区域，滑到新按钮就TTS播报名称
500ms内同一位置双击触发确认（和iOS VoiceOver逻辑一致）
每次页面onShow强制reset所有触摸状态，防止跨页面状态泄漏（这个bug我们修到最后才发现是ref名写错了）
横竖屏切换、布局变化时自动重新缓存按钮位置
社会价值思考
说实话，明阅这个产品本身的商业价值并不高——它是纯公益、无广告、纯离线的，我也没打算靠它赚钱。但我希望它能为无障碍领域提供一个被忽视已久的方向。
我们以为的"无障碍"，和盲人真正需要的，差得很远
做这个项目之前我和大多数人一样，觉得"手机自带读屏不就够了吗？"真正做了才知道：
盲人朋友拿着手机，经常连现在几点都不知道——拉下通知栏这个简单的动作，在没有视觉的情况下极其困难，要摸半天还经常误触
低视力老人想看书，系统字体调到最大还是看不清，App自己的字体又不跟着系统变，黑底白字的高对比度主题更是几乎没有App做
几乎所有App的"无障碍适配"，就是给按钮加个contentDescription，让系统读屏能读出来——但这只是"能读"，不是"好用"。读屏会把广告、弹窗、按钮、正文混在一起读，盲人想读一段书，要先听十几秒无关的UI元素。
我们总说"技术普惠"，但大多数时候，我们只是让盲人"能用上"，从来没让他们"用得舒服"。
无障碍不是"适配系统读屏"，而是重新设计产品
明阅想做的，不是在普通阅读App上补几个无障碍标签，而是从交互逻辑开始，完全为视障用户重新设计：
既然看不见，那就不要让他们"找按钮"——手指滑到哪里就读哪里，永远知道自己摸到了什么
既然双击才是确认，那就不要让单击触发任何操作，永远不会误触
既然是听书，那就不要让任何UI元素打断朗读，打开就是正文，翻页就是左右滑，像翻书一样自然
既然低视力需要大字，那就不要让大字把排版挤乱，字体从16px到80px无级调节，行距字间距页边距全部可自定义
这些细节说起来简单，但没有多少产品愿意做——因为视障用户是"少数群体"，做了也带不来多少DAU，带不来多少收入。
我希望明阅是一个开始
我一个人能做的很少。明阅现在还有很多bug，功能也不完善。但我希望它能证明一件事：
为视障用户做产品，不需要多么高深的技术，只需要你真的站在他们的角度想问题。
你不需要等系统读屏进化，你可以自己在App里实现滑动探索、双击确认的交互；你不需要做复杂的AI识别，只要每一步操作都给一个语音反馈，盲人就能独立使用；你不需要做多大的功能，只要把"导入-看书"这一条链路做顺，就真的能帮到1700万人。
如果有更多开发者看到这个项目，意识到"原来无障碍可以这么做"，愿意在自己的产品里多花一点心思考虑视障用户的需求，那这个项目的价值，就比它本身作为一个阅读App要大得多。
技术的价值，从来都不是让强者更强，而是让原本被忽略的人，也能有平等享受技术便利的权利。
最后想说的话
做这个项目的过程中，我无数次想放弃。AI演戏、bug找不到、身体垮掉，每一个坎都好像跨不过去。 但当PDF终于跑通、当我闭着眼睛真的可以不看屏幕读完一本书的时候，我觉得一切都值了。
中国有1700万视障朋友，他们不应该被互联网遗忘。 感谢TRAE，让我一个不会写uni-app的前端，也能为他们做出点什么。