@ghwolf007 好的，谢谢，价格很诱人

t/1008061
这个方案对比不错，非常详细了，适合各种不同预算，推荐有需要的朋友参考。

这个方案对比不错，非常详细了，适合各种不同预算，推荐有需要的朋友参考。

谢谢给的参考，你动手能力强，很棒。
2080ti 魔改 22G 2488 ，这个跑 SD 出图 512*512 ，大概几秒能出一张？

@SoulClinic 归来仍是少年！

把 html 后缀改成 hta 试试。或者搜索下 hta 。只能使用 IE，并且对版本可能有要求。

经历和你很像啊...
后来有了家庭，有了孩子，比特币也买过啊，亏了 50%...
以前一起学习和创业的同学或朋友，市值高的都超 100 亿了。
所以呢...所以没有所以了.
自己是个爱好比星星还多的人，也爱家爱孩子。那就安心坐家吧。
最近 7、8 年，都过着钱比人少，时间比人多的日子，把自己的爱好一个个的去实践过。
最近 2 年，洗碗拖地做卫生，教孩子念书...
心理上有落差那是肯定的，特别是在媒体上看到以前认识朋友的公司广告之类的时候。
但也还好，他们过得比我辛苦多了。
我每天可以睡睡懒觉，大家挤在路上的时候，我可以很闲的喝茶看书。
钱不多，理理财，省点也够花。创业中学的各种技能，对付生活中遇到的各种问题还是绰绰有余的。
大概就是这样...换个维度看，不算非常好，但也该知足了。
你有经济基础，太幸福有没有，把目标设定小些，创业只是口井，站的高一些，井外面的世界更精彩。

1、拒绝是对的，无需有负担
2、但手头不差钱的话，拿 5K 当白送更好，或许他真遇上难事了呢，能帮一点是一点
3、人生在世，太世故不好，太懵懂一样不好
4、自己落难了，别指望别人，再难，靠自己，恢复的更快

“检疫“、”局”，这两字词已经告诉你答案了。

@linhua 用无人机会不会更好?

在自己能力范围内做过一些这样的小尝试。楼主要的远程视频这些，都不算问题。
真正的问题是农作物本身，比如杀虫。我尝试过不用农药，抓虫子就够呛。能想象到晚上 12 点黑灯瞎火的在菜地里用镊子抓虫么？哥还好是搞 IT 的能熬夜，要换成妹子，不知道该怎么办。别问我为什么要晚上，因为这厮就是晚上 12 点多从地里爬出来吃叶子的啊。
再接着 1K 亩，劳动力也是个问题，比如不用草甘膦除草，在春季有些地区，这边刚刚除好，那边又长出来了，这真不是夸张。你看着一片草芽子，真的是没招。
同意以上大部分同学的观点， IT 在这个项目中，真的不是什么难事。真正难的是关于土地，关于种植术，关于农民。。。这些才是头大的地方。
看了许多农业项目，最好还是给点建议好了。真要做，尝试去谈一些已经大规模进入收获阶段的农业合作社。出点子，甚至合作，帮助他们更好的销售产品、或者预售、或者会员制。千千万万不要在没有任何生成经验时靠热情全链条介入农业，会屎的一塌糊涂的。
不过最后还是要祝福你，未来属于有梦想的你。别看大家泼了一大堆冷水，如果你执意要去做，想好了，就去实践吧。说不定万一成功了呢。。。

我在福州，刚收的玉米， 2-3 根左右，品质还可以。能出多少根，这个看品种的。

@icedx 开公司会怎样？成功概率更大吗？

几条路
1 、学习拿文凭，报大公司。时间换门票
2 、小公司，多干活，混经验。时间换经验
3 、创业。自由自在，冷暖自知

然后串起来，最优化的线路大概是 213
3k 是低了，但是能有机会把控项目全程，机会也很难得。你工资低和老板说过没？不要臆想，和老板说出你想要的。

够用省钱是硬道理，又不是找老婆要一次到位。

@passion336699 是啊，把所有关于具体商品的差异都用 XML 中描述和储存。
XML 的字段内容类似这样:
<商品属性>
<商品编码>SPU_ID</商品编码>
<颜色>
<白色>
<16G 价格=5000></16G>
<64G 价格=6000></64G>
</白色>
<玫瑰金>
<16G 价格=5000></16G>
<64G 价格=6000></64G>
<玫瑰金>
</颜色>
<其他属性.../>
</商品属性>

然后你要写什么就都放里面好了，最后做一个解析器去解析和呈现 TA 。这个 XML 的结构是可以有版本的，比如你今天做手机有如上属性，过一段日子你可能要做服装，那么在这个基础上增加元素就好了。
这样你主表中只要存储诸如 SPU_ID 这样的所有商品都具备的共有属性就可以。
理论上只要是有关联结构的存储，你最终总能实现你所想要的功能。只是实现的代价高低之分。

其实写着写着，觉得楼上说的没错，有些偏题了。我这个说的是存储灵活的问题，你问的可能是入参规范和涉及的合理数据结构的问题。
如果是希望入参一致，那么按照楼上一个 SKU 对应一条记录（或一个 XML 内容），应该是比较好的做法了，原则上都是以 SKU 为单位进行存储。

实际上，商品系统的开发，有非常多的因素需要考虑。不仅仅是满足当下需求的问题，你得知道，给你需求的业务口人员，可能自己都搞不懂真实的需求是什么，或者会变成什么。
如果是我做,对于一个全新的电商项目的商品部分的数据结构,说一个偷懒的做法,仅供参考:
1 、分析提取商品的最大共性,比如名称,描述等形成商品表；
2 、然后所有个性信息,比如颜色,规格等等,全部用一个 XML 描述。这个 XML 描述也存在上述商品表的某个字段中；
3 、针对后台维护和前端显示，通过前端 JS 实现各种需求下数据的各种常见呈现和操作，同时 JS 能够对不同版本的商品 XML 向下兼容。

这样做的好处是，减低未知需求变化对数据层的影响。反正业务部门需求天天都在变，我们最终只在 XML 上做描述就可以实现这一块的业务变更。技术资源主要投入在通用组件的开发上，比如根据 XML 结构自动形成下拉条，多选框之类的东西。

再有像库存数量变化的问题，实际运行中会有很多情况发生，比如下单暂未付款的库存锁定、释放等等，这个和业务部门的需求都是密切相关的，也许这次是要下单就减库存，也许下次就变成未付款超时释放库存，这些都是不确定的。那这种情况下，技术部门当下要考虑的就是，怎样做好技术储备，在需求变化时用最小的投入最快的满足需求。
以上，参考参考。

小心使得万年船.我 20 来岁的时候也遇到过,对方还在酒楼摆了一桌子饭菜请我.
最后还是婉言回绝了.
有的事情,即便只有 1%的可能出问题.但是这 1%的问题就会让你的生活 100%的完蛋.那么这种事,还是不干为好.