这次我记录的是一次用 TRAE SOLO 移动端完成表单校验功能的经历。功能本身不大，但过程比较完整：从发现问题、理解已有代码、调整实现，到最后验证交互，都不是单纯贴代码能说明白的。
项目里有一个「新增客户信息」页面，里面包含姓名、手机号、备注等字段。之前页面只做了最基础的非空判断，用户如果手机号输错，比如少一位、输入了空格，页面仍然可以提交。后端虽然也会拦截，但前端没有及时提示，用户体验比较差。这个问题我之前记在待办里，一直没抽出整块时间处理。
某天午休时，我打开 TRAE SOLO 移动端，想着先看看能不能把这个功能补掉。因为手机屏幕有限，我没有一上来就改代码，而是先让它帮我定位表单提交相关逻辑。它帮我找到了页面组件、提交方法和当前校验函数。看完后我确认，原来的校验逻辑只判断了姓名是否为空，手机号只是简单读取，没有做格式处理。
我这次的目标很明确：不做复杂表单库迁移，不重构页面结构，只补上必要的手机号校验和错误提示。这样做的原因也很简单，这个页面已经在线上使用，贸然改动太多反而容易引入新问题。小步修改、保持原有结构，是我当时最稳妥的选择。
具体思路分成三步。第一步，在提交前统一清理手机号，把用户输入里的空格去掉，避免因为复制粘贴带来的隐藏问题。第二步，判断手机号长度和格式是否符合要求，如果不符合，就直接提示用户，不继续提交。第三步，把错误提示放在原有提示体系里，不额外引入新的 UI 方案，保证页面风格一致。
实现时我让 TRAE SOLO 先根据已有代码生成一个最小修改方案，然后我逐行看它改了哪里。它最初给出的方案比较完整，但我删掉了一些不必要的抽象，比如单独新建多个工具函数。这个功能目前只有一个页面使用，直接在当前校验函数里处理更直观，也更符合这次小修小补的目标。
调整后，提交逻辑变得更清楚：用户点击保存，前端先检查姓名，再检查手机号。如果手机号为空或格式不正确，页面立即给出提示；只有校验通过后，才会继续调用保存接口。这样既减少了无效请求，也让用户能更快知道哪里填错了。
我在手机上验证了几个场景：手机号为空、手机号少一位、手机号中间带空格、手机号正确填写。前几种都能被拦截，正确填写时可以正常提交。因为这次没有改动接口结构，也没有改动页面布局，所以风险相对可控。
这次使用 TRAE SOLO 移动端的感受是，它比较适合完成这种「边界明确的小功能」。如果要做大型模块设计，我还是会选择电脑；但如果只是补一个校验、修一个判断、确认一个调用链，移动端完全可以胜任。尤其是在午休、等车、出门没带电脑的时候，它能让一些原本被搁置的小问题被及时处理掉。
我觉得移动生产力的重点不是炫技，也不是证明手机可以完全替代电脑，而是让开发工作多一种更灵活的入口。过去我可能会把这种小问题拖到晚上再处理，结果经常被其他事情打断。现在用 TRAE SOLO 移动端，至少可以先完成分析和小范围修改，等回到电脑前再做更完整的检查。
这次补表单校验功能就是一个很真实的例子：没有复杂代码，没有夸张效果，但它确实解决了一个用户会遇到的问题，也让我第一次比较完整地体验了移动端参与实际开发的流程。
