JG

如果是机械表， 可能是声波的问题 。 或者朗诵的时候， 手势特别丰富。

每个贡献者的功底有限， 所以只能尽力注明。 如有异议的欢迎提 PR 注明。

貌似和#93差不多，但没有找到来源解释。 我倾向于用后者 ：）

我明白你的意思， 比较熟悉的诗词作者，诗词和诗词作者一样都有熟知的一小部分和陌生的大部分。还有一部分属于五代十国朝代里，作者国号朝代问题和诗词著作时间地点， 可能在学界里面都没有真实的时间。 /头大

：） 感谢你的建议， 使用 UUID 确实是个很好的方式，但目前没有相应的系统做关联（快捷跳转）。 比如我看一首诗词关联了某个作者 ID， 在 Github 上我只能通过检索文本的形式找到这个作者。 我曾经考虑做个纠错系统， 所有更改全部记录在纠错系统上， 拟订一个周期开放数据。 这个计划一直搁置。 欢迎讨论

@zhongwencm 多谢你的记录和整理， 有时间我会查一查整理修复下。

我也不能确定应该参考哪个版本， 事实上这种事情很常见。 传承过程随着手抄， 录入，或者再次创作都有可能会变动。 我们都不是这个领域的专家，都不确定应该参考哪个. @O70 老哥 有什么好的想法没有？

@O70 您是指今天的那个npm打包安装工具的仓库吗？ 因为这是个工具不是内容， 这个数据库应该是录入到数据库里面的，初衷是做一个方便开发者导入使用的古典国学文集数据库，如果一个npm的打包过程放到README.md中， 我想以后肯定会有更多的打包安装过程写进来， 这样这个仓库的作用就太多了， 不利于数据库的丰富性和质量。 我的想法是基于数据做的工具和平台做引用（做下推广， 让更多的人看到），**属于古典国学文集部分还是非常欢迎在此仓库维护内容的**。

https://github.com/chinese-poetry/huajianji https://github.com/chinese-poetry/poetry-calendar https://github.com/chinese-poetry/weapp-calendar 这个尝试过， 都是些小的工具。 多用户社交型的web平台也做过（https://cornus.herokuapp.com/）， 但因为工作问题就搁置了。 至于什么时候再去做， 还没有计划。 总是想做很完美的产品， 往往急功近利导致夭折。。。 ：）

哇， 漂亮的作品， 我可以加到 readme中的案例展示吗？ ------------------------------------------------------ 更新： 抱歉， 看错了， 原来是现代诗。 真的好漂亮 👍